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Beschreibung 

Verfahren zum Konf igurieren eines konf igurierbaren Hardware- 
Blocks 

Die vorliegende Erfindung betrifft ein Verfahren gemafi dem 
Oberbegriff des Patentanspruchs 1, d.h. ein Verfahren zum 
Konf igurieren eines konf igurierbaren Hardware-Blocks, so dali 
dieser durch Befehle oder Bef ehlsf olgen vorgegebene arithme- 
tische und/oder logische Operationen oder Operationsf olgen 
ausfuhren kann . 

Ein derartiges Verfahren wird unter anderem benotigt, urn die 
sogenannte s-unit eines sogenannten >S<puters zu konfigurie- 
ren. Ein >S<puter ist eine programmgesteuerte Einheit, die 
insbesondere durch die Verwendung eines konf igurierbaren 
Hardware-Blocks in dem die Befehle abarbeitenden Tail in der 
Lage ist, mehr als einen Befehl pro Prozessortakt auszufuh- 
ren. 

Ein solcher >S<puter ist beispielsweise aus der EP 0 825 540 
Al bekannt- 



Der grundlegende Aufbau eines >S<puters ist in Figur 11 ge- 
25 zeigt und wird nachfolgend unter Bezugnahme hierauf beschrie- 
ben . 



Der Vollstandigkeit halber sei bereits an dieser Stelle dar- 
auf hingewiesen, daft der >S<puter, insbesondere dessen die 
30 Befehle abarbeitende Teil nur teilweise (nur so weit es fur 
die vorliegend naher betrachteten konf igurierbaren Hardware- 
Blocke und deren Konf igurierung von Bedeutung ist) dar- 
gestellt und beschrieben ist. 
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Der >S<puter gemaii Figur 11 umfaiit eine Vordecodier-Einheit 
(predecode unit) 1, einen Instruktions-Puf f er (instruction 
buffer) 2, eine Decodier-, Umbenennungs- und Lade-Einheit 
(decode, rename & load unit) 3, die bereits erwahnte s-Para- 
5 digmen-Einheit (s-unit) A, einen Daten-Cache (data cache) 5, 
und eine Speicher-Schnittstelle (memory interface) 6^ wobei 
die s-unit 4 aus einem Strukturprogrammier-Puf f er (programma- 
ble structure buffer) 41, einer Funktionseinheit mit pro- 
grammierbarer Struktur (functional unit with programmable 

10 structure) 42, einem Integer/Adreliinstruktions-Puf f er 

(integer/address instruction buffer) 43 und einem Register- 

^ block (integer register file) 44 besteht. 

Die Besonderheit des >S<puters besteht insbesondere in dessen 
15 s-unit 4, genauer gesagt in der functional unit 42 derselben. 
Die functional unit 42 ist eine konf igurierbare Hardware, die 
basierend auf vom >S<puter auszuf uhrenden Befehlen oder 
Bef ehlsf olgen dynamisch so konf igurierbar ist, dafi sie die 
durch die Befehle oder Bef ehlsf olgen vorgegebenen Aktionen 
20 bzw. Operationen ausfiihren kann . 

Vom >S<puter auszuf iihrende Instruktionen (genauer gesagt 
diese reprasentierende Code-Daten) gelangen aus einem nicht 
gezeigten Speicher uber das memory interface 6 in die pre- 

25 decode unit 1, wo sie vordecodiert werden; dabei konnen zu 

den Code-Daten beispielsweise Inf ormat ionen hinzugefugt wer- 
den, die die spatere Decodierung in der decode, rename & load 
unit 3 erleichtern. Die Code-Daten gelangen dann uber den 
instruction buffer 2 in die decode, rename & load unit 3, wo 

30 die Ausfuhrung der durch die Code-Daten reprasentierten 
Befehle vorbereitet wird. Diese Vorbereitung umfafit die 
Decodierung der Code-Daten, die Konf igurierung bzw. Struktu- 
rierung der functional unit 42, die Initialisierung bzw. 
Verwaltung des integer register file 44, und das Starten der 

35 wunschgemaB konf igurierten functional unit 42. 
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Die Strukturierung bzw. Konf igurierung der functional unit 42 
erfolgt unter Verwendung von die gewunschte Konf iguration 
reprasentierenden Konf igurat ions-Daten, die von der decode, 
5 rename & load unit 3 in den programmable structure buffer 41 
geschrieben werden. Diese, die gewunschte Konf iguration re- 
prasentierenden Konf igurations-Daten werden in der decode, 
rename & load unit 3 kreiert; sie konnen aber auch schon in 
codierter Form in den Code-Daten enthalten sein. 

10 

_ Die functional unit 42 ist dazu ausgelegt, Daten aus dem 

^^^k register file 44 und/oder dem data cache 5 auszulesen, die 

^^1^ ausgelesenen Daten arithmetisch und/oder logisch zu verarbei- 
ten, und das Ergebnis der Verarbeitung reprasentierende Daten 
15 in das register file 44 und/oder den data cache 5 einzu- 
schreiben . 

Bei geeigneter Initialisierung des register file 44 und bei 
geeigneter Konf igurierung der functional unit 42 hat der Be- 
20 trieb der functional unit 42 die Ausfuhrung der Operationen 

zu Folge, die durch die Ausfuhrung der Befehle, auf der Basis 
welcher die Initialisierung des register file 44 und die Kon- 
figurierung der functional unit 42 erfolgten, zu bewirken 
sind. 

25 

Die Vornahme der durch die Ausfuhrung von Instruktionen zu 
bewirkenden Aktionen durch eine entsprechend konf igurierte 
Hardware (die functional unit 42) ist bekanntlich bedeutend 
schneller als die Ausfuhrung der Befehle in den "normalen" 
30 Arithmetisch/Logischen Einheiten (ALUs) von herkommlichen 

programmgesteuerten Einheiten. Dies gilt in besonderem Mafie 
fur den Fall, daB die Hardware (die functional unit 42) so 
konfiguriert ist, daft durch deren Betrieb ein Ergebnis er- 
zielbar ist, das der Ausfuhrung mehrerer auf einanderf olgender 
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Befehle (eines mehrere Befehle umfassenden Makrobef ehls ) ent- 
spricht. 

Bezuglich weiterer Einzelheiten zum Aufbau, der Funktion und 
5 der Wirkungsweise von >S<putern und der darin enthaltenen 
konf igurierbaren Hardware wird auf die vorstehend bereits 
erwahnte EP 0 825 540 Al verwiesen. 

Der Vollstandigkeit halber sei angemerkt, dali nicht alle 
10 Aktionen, die durch die vom >S<puter auszuf uhrenden Befehle 
zu bewirken sind, durch die functional unit 42 ausfuhrbar 
^^^^ sind. Befehle wie insbesondere zur Programmablauf steuerung 
^^^1 bzw. Kontrollf luBsteuerung dienende Befehle wie beispiels- 
weise Branch-, Jump-, No-Operation-, Wait- und Stop-Befehle 
15 werden in der Regel auf her kommliche Art und Weise ausgefuhrt 
werden . 

Nichtsdestotrot z kann durch die Verwendung konf igurierbarer 
Hardware-Blocke wie der functional unit 42 im allgemeinen 
eine hohere Anzahl von durch auszuf uhrende Befehle zu bewir- 
kenden Aktionen pro Zeiteinheit ausgefuhrt werden als es mit 
herkommlichen programmgesteuerten Einheiten der Fall ist, 
also mehr als ein Befehl pro Prozessortakt abgearbeitet wer- 
den . 

Voraussetzung ist naturlich, dafi die Hardware-Blocke schnell 
konfiguriert und effizient genutzt werden. 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, 
30 das Verfahren gemafi dem Oberbegriff des Patentanspruchs 1 

derart weiterzubilden, dafj die Hardware-Blocke schnell kon- 
figurierbar und effizient nutzbar sind. 

Diese Aufgabe wird erf indungsgemafi durch die im kennzeichnen- 
35 den Teil der Patentanspruchs 1 beanspruchten Merkmale gelost. 
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Demnach ist vorgesehen, dali fur die Umsetzung der abzuarbei- 
tenden befehle in eine Hardware-Block-Struktur die Schritte 

- Ermittlung der zur Ausfuhrung eines jeweiligen Befehls be- 
notigten Art von Teileinheit des konf igur ierbaren Hardware 
Blocks , 

- Auswahl einer noch nicht anderweitig belegten Teileinheit 
der zuvor ermittelten Art, und - sofern eine solche Teil- 
einheit gefunden werden konnte - 

- Konf igurieren von um die ausgewahlte Teileinheit herum vor 
gesehenen konf igur ierbaren Verbindungen 

ausgef iihrt werden . 

Durch eine derartige Vorgehensweise lassen sich zu konfigu- 
rierende Hardware-Blocke mit minimalem Aufwand automatisch 
konf igurieren . Die Konf igurat ion erfolgt dabei sehr schnell 
und nutzt die Komponenten des Hardware-Blocks optimal aus; s 
konf igurierte Hardware-Blocke lassen sich sehr effizient ein 
setzen. 

Vorteilhafte Weiterbildungen der Erfindung sind den Unter- 
anspruchen, der nachf olgenden Beschreibung und den Figuren 
entnehmbar . 

Die Erfindung wird nachfolgend anhand von Ausf uhrungsbeispie 
len unter Bezugnahme auf die Figuren naher erlautert. Es zei 

gen . 

Figuren lA bis ID ein Beispiel fur einheitliche Befehls- 

Formate, die die umzuset zenden Befehle im betrach 
teten Beispiel aufweisen sollten oder in die sie 
vor Beginn der Umsetzung vorzugsweise gebracht 
werden. 
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Figur 2 eine bei der hardwaremafiigen Realisierung der Um- 
setzung verwendete Look-Up-Table, 

Figuren 3A und 3B das Format der aus der Look-Up-Table gemafj 
5 Figur 2 ausgegebenen Daten, 

Figur 4 das Blockschaltbild einer Schaltung zur Auswahl 

und Konf igurierung einer zur Ausfuhrung eines Be- 
fehls benotigten Teileinheit des Hardware-Blocks, 



10 



15 



Figur 5 das Blockschaltbild einer Schaltung zur Festlegung 
der Daten- und/oder Signalquellen und der Daten- 
und/oder Signalziele fur die durch die Schaltung 
gemali Figur 4 ausgewahlte Teileinheit, 

Figur 6 das Blockschaltbild einer Schaltung zur Handhabung 
von in den umzusetzenden Befehlen enthaltenen Kon- 
stanten, 

20 Figur 7 das Blockschaltbild einer Schaltung zur Durchfuh- 

rung des sogenannten Data Forwarding, 

Figur 8 einen sogenannten Cross-Bar-Switch zum Einschrei- 
ben der Konf igurations-Daten in einen temporaren 
25 Bitstrom, 

Figur 9 eine Anordnung zum Einschleusen des temporaren 
Bitstroms in einen Hauptbit strom, 

30 Figur 10 eine komplette Anordnung zum Umsetzen von Befehlen 

in Konf igurations-Daten zur wunschgemalien Konfigu- 
rierung des Hardware-Blocks, 



n o 



Figur 11 den prinzipiellen Aufbau eines >S<puters, und 

35 
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Figur 12 den prinzipiellen Aufbau eines Hardware-Blocks der 
vorliegend naher betrachteten Art . 

Zur Erleichterung des Verstandnisses wird zunachst der prin- 
zipielle Aufbau eines Hardware-Blocks beschrieben, der durch 
das danach beschriebene Verfahren konf igurierbar sein soil. 

Der prinzipielle Aufbau eines solchen Hardware-Blocks ist in 
Figur 12 gezeigt, Der gezeigte Hardware-Block ist dazu aus- 
gelegt ist, abhangig von seiner Konf igurierung in einer 
Speichereinrichtung gespeicherte Daten auszulesen, die aus- 
gelesenen Daten arithmetisch und/oder logisch zu verarbeiten 
und das Ergebnis der Verarbeitung represent ierende Daten in 
die Speichereinrichtung einzuschreiben; er ist beispielsweise 
als die functional unit 42 des >S<puters gemafi Figur 11 ein- 
setzbar . 

Die Speichereinrichtung, aus welcher der konf igurierbare 
Hardware-Block Daten ausliest und in welche der Hardware- 
Block Daten einschreibt, kann innerhalb oder aulierhalb des 
Hardware-Blocks vorgesehen sein; im vorliegend betrachteten 
Beispiel wird die Speichereinrichtung durch das register file 
44 des >S<puters gemaii Figur 11 gebildet. Der Hardware-Block 
ist ein asynchrones Schaltnetz zwischen den Aus- und Eingan- 
gen der Speichereinrichtung; die Bestandteile des Hardware- 
Blocks sind asynchron miteinander gekoppelt. 

Die Speichereinrichtung ist vorzugsweise von aulierhalb des 
Hardware-Blocks vor der Inbetriebnahme desselben initiali- 
sierbar; denkbar ware aucK, dafi der Hardware-Block die 
Initialisierung der Speichereinrichtung selbst veranlaiit oder 
durchf uhrt . 
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Der in der Figur 12 gezeigte Hardware-Block weist eine oder 
mehrere arithmetische Einheiten AUl, AU2, eine oder mehrere 
Vergleichs-Einheiten CU, einen oder mehrere Multiplexer eines 
ersten Typs MUXAl, MUXA2, MUXA3^ einen oder mehrere Multi- 
plexer eines zweiten Typs MUXB, und einen oder mehrere De- 
multiplexer DEMUX auf. 

Die arithmetischen Einheiten AUl, AU2 weisen im betrachteten 
Beispiel zwei Eingangsanschlusse , einen AusgangsanschlufJ und 
einen Steueranschluft auf. Den arithmetischen Einheiten AUl, 
AU2 obliegt es, die uber deren Eingangsanschlusse eingegebe- 
nen Eingangssignale arithmetisch und/oder logisch zu verar- 
beiten. Die Operationen, die durch die arithmetischen Ein- 
heiten AUl^ AU2 ausfuhrbar sind, konnen fest vorgegeben oder 
individuell einstellbar ( konf igurierbar ) sein; sie umfassen 
insbesondere arithmetische Operationen wie Addition, Subtrak- 
tion, Multiplikation, Division etc., logische Verknupf ungen 
wie UND-Verkniipf ungen, ODER-Verkniipf ungen. Invert ierung, 
Komplementbildung etc., arithmetische und logische Shift- 
Operationen, und Datentransf ers ( Durchschaltung eines der 
eingegebenen Signale zum Ausgangsanschlufi ) . Die arithmeti- 
schen Einheiten AUl, AU2 sind nicht mit den Arithmetisch/- 
Logischen Einheiten (ALUs) her kommlicher programmgesteuerter 
Einheiten wie Mikroprozessoren, Mikrocontrollern etc. gleich- 
zusetzen; die von ihnen ausfiihrbaren Operationen sind be- 
grenzt, so dafj der Aufbau der arithmetischen Einheiten AUl, 
AU2 vergleichsweise einfach bleiben kann. Uber die Steuer- 
anschliisse der arithmetischen Einheiten AU1, AU2 ist fest- 
legbar, ob die betreffende arithmetische Einheit die Opera- 
tion, zu deren Ausfuhrung sie vorgesehen ist, ausfuhrt oder 
nicht. Dies ermoglicht die praktische Umsetzung von Befehlen, 
deren Ausfuhrung vom Vorliegen einer bestimmten Bedingung ab- 
hangt. Die Bedingung kann beispielsweise der Zustand eines 
bestimmten Flags sein: ist das Flag gesetzt, wird die der 
betreffenden arithmetischen Einheit obliegende Aufgabe (bei- 
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spielsweise eine Addition) ausgefiihrt, andernfalls nicht 
(Oder umgekehrt) . Derartige, nachfolgend als " kondit ionierte 
Befehle" bezeichnete Befehle ermoglichen es, die schwer hand- 
habbaren bedingten Sprungbef ehle zu eliminieren; sie warden 
5 spater noch genauer beschrieben. 

Die Vergleichs-Einheit CU weist im betrachteten Beispiel zwei 
Eingangsanschlusse und einen AusgangsanschlufJ auf . Der Ver- 
gleichs-Einheit CU obliegt es, die an deren Eingangsanschlus- 

10 sen anliegenden Signale oder Daten Vergleichsoperationen zu 
unterziehen. Die Operationen, die durch die Vergleichs- 
Einheit CU ausfuhrbar sind, konnen fest vorgegeben oder 
individuell einstellbar ( konf igurierbar ) sein; sie umfassen 
beispielsweise Grofier-, Grolier/Gleich-, Kleiner-, Kleiner/- 

15 Gleich-, Gleich-, und Ungleich-Vergleiche und Uberpruf ungen 
auf wahr (TRUE) und unwahr (FALSE) . Der Ausgangsahschlufi der 
Vergleichs-Einheit CU ist uber den nachfolgend noch genauer 
beschriebenen Demultiplexer DEMUX mit den Steueranschlussen 
der arithmetischen Einheiten AUl, AU2 verbunden. Vom Ergebnis 

20 der in der Vergleichs-Einheit CU ausgefiihrten Operation hangt 
es also ab, ob die arithmetischen Einheiten AUl, AU2 die 
Operation, zu deren Ausfuhrung sie vorgesehen sind, ausfuhren 
oder nicht - 

25 Die Multiplexer des ersten Typs MUXAl, MUXA2, MUXA3, der 
Multiplexer des zweiten Typs MUXB, und der Demultiplexer 
DEMUX dienen zur Auswahl der Daten- und/oder Signalquellen 
und der Daten- und/oder Signalziele. Genauer gesagt dienen 

30 - der Multiplexer MUXAl zur Auswahl der Quellen der den Ein- 
gangsanschlussen der arithmetischen Einheit AUl zugeflihrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
quellen sind im betrachteten Beispiel das register file 44 
und andere arithmetische Einheiten) , 

35 
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- der Multiplexer MUXA2 zur Auswahl der Quellen der den 
Eingangsanschlussen der arithmetischen Einheit AU2 zuge- 
fuhrten Daten und/oder Signale (mogliche Daten- und/oder 
Signalquellen sind im betrachteten Beispiel das register 

5 file 44 und andere arithmetische Einheiten) , 

- der Multiplexer MUXA3 zur Auswahl der Quellen der den 
Eingangsanschlussen der Vergleichs-Einheit CU zugefuhrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 

10 quellen sind im betrachteten Beispiel das register file 44 
und die arithmetischen Einheiten) , 

- der Multiplexer MUXB zur Auswahl der Quellen der dem 
register file zugefuhrten Daten und/oder Signale (mogliche 

15 Daten- und/oder Signalquellen sind im betrachteten Beispiel 
die arithmetischen Einheiten und/oder das register file 
selbst) , 

- der Demultiplexer DEMUX zur Auswahl des oder der Ziele fur 
20 die von der Vergleichs-Einheit CU ausgegebenen Daten 

und/oder Signale (mogliche Daten- und/oder Signalziele sind 
im betrachteten Beispiel die arithmetischen Einheiten) . 

1^ Die Multiplexer des ersten Typs weisen mehrere Eingangs- 

25 anschlusse und zwei Ausgangsanschlusse auf, die Multiplexer 
des zweiten Typs mehrere Eingangsanschliisse und einen Aus- 
gangsanschluft, und der Demultiplexer einen EingangsanschluB 
und mehrere Ausgangsanschlusse. 

30 Die Multiplexer und der Demultiplexer weisen in der Figur 12 
nicht gezeigte Steueranschliisse auf, tiber welche einstellbar 
ist, welche Eingangsdaten und/oder -signale auf welche Aus- 
gangsanschlusse durchgeschaltet werden. Die Anzahl der 
Steueranschlusse hangt von der erf orderlichen Anzahl der 

35 verschiedenen Zuordnungs-Kombinationen ab; bei 32 Eingangs- 
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anschlussen und zwei Ausgangsanschlussen sind beispielsweise 
10 Steueranschlusse erf orderlich, um an beliebigen Eingangs- 
anschlussen anliegende Signale und/oder Daten auf beliebige 
Ausgangsanschlusse durchschalten zu konnen. Im Fall des Ein- 
5 satzes des Hardware-Blocks als functional unit 42 im >S<puter 
gemafJ Figur 11 sind die Steuersignalanschliisse vorzugsweise 
mit dem programmable structure buffer 41 verbunden, so dafi 
die in diesen eingeschriebenen Konf igurat ions-Daten im we- 
sentlichen unmittelbar zur Multiplexer-Ansteuerung verwendbar 
10 sind. Die im programmable structure buffer 41 gespeicherten 
Konf igurations-Daten umfassen vorzugsweise auch die Konfigu- 
rations-Daten zur Festlegung der jeweiligen Funktion der 
arithmetischen Einheiten AUl, AU2 und der Vergleichs-Einheit 
CU, 

15 

Durch die arithmetischen Einheiten AUl, AU2, die Vergleichs- 
Einheit CU, die Multiplexer des ersten Typs MUXAl, MUXA2, 
MUXA3, den Multiplexer des zweiten Typs MUXB, und den De- 
multiplexer DEMUX wird der Hardware-Block in die Lage ver- 

20 setzt, in einer Speichereinrichtung (im register file 44) 

gespeicherte Daten auszulesen, die ausgelesenen Daten arith- 
metisch und/oder logisch zu verarbeiten und das Ergebnis der 
, Verarbeitung reprasentierende Daten in die Speichereinrich- 

^ t^ung (das register file 44) einzuschreiben . 

25 

Der in Figur 12 gezeigte und unter Bezugnahme darauf 
beschriebene Hardware-Block ist nur zur Erlauterung des 
grundlegenden Aufbaus gedacht . In der Praxis werden die 
arithmetische Einheiten, die Vergleichs-Einheiten, die 
30 Multiplexer, und die Demultiplexer in einer deutlich grofteren 
Anzahl vorgesehen werden als es beim Beispiel gemaf^ Figur 12 
der Fall ist. Der Hardware-Block ist vorzugsweise so 
dimensioniert , daft normalerweise samtliche Operationen, die 
von einem spater noch naher beschriebenen, sogenannten 
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Hyperblock zu bewirken sind, auf ein Mai in ihn 
einprogrammierbar sind . 

Die im Hardware-Block vorgesehenen Daten- und/oder Signal- 
pfade konnen durch einzelne Leitungen oder durch Busse gebil- 
det werden, wobei es sich als vorteilhaft erweisen kann, wenn 
in den einzelnen Teileinheiten des Hardware-Blocks oder im 
Bus-System konf igurierbar ist, wie viele und/oder welche Bus- 
leitungen zu beriicksichtigen sind. 



Die Konf igurierung eines Hardware-Blocks nach Art der Figur 
12 kann basierend auf Befehlen oder Bef ehlsf olgen erfolgen. 
Setzt man Befehle oder Bef ehlsf olgen in entsprechende Hard- 
ware-Block-Strukturen urn, so ist der so konf igurierte Hard- 
15 ware-Block als Ablauf einheit fur sequentielle Bef ehlsf olgen 
nutzbar. Diese Form der Hardware-Block-Konf igurierung wird 
nachfolgend auch als struktur-prozedurale Programmierung 
bezeichnet . 

20 Ausgangspunkt fur die struktur-prozedurale Programmierung 

kann ein in einer Hochsprache wie beispielsweise C-I-+ etc. 
geschriebenes Programm sein. Dieses Programm wird durch einen 
^ y Compiler ubersetzt, und der dabei erhaltene Code wird 
\- ( vor zugsweise hyperblock-weise ) in Strukturinf ormationen 

25 umgesetzt, basierend auf welcher der zu konf igurierende Hard- 
ware-Block konf igurierbar ist. Was unter einem Hyperblock zu 
verstehen ist, wird spater noch genauer beschrieben werden. 

Ausgangspunkt fur die struktur-prozedurale Programmierung 
30 kann selbstverstandlich auch ein in Assembler geschriebenes 
Oder sonstiges Programm sein. Die Art und Weise der Pro- 
grammierung (funktional, imperativ, ob j ekt-orient iert ^ ...) 
ist ebenfalls keinen Einschrankungen unterworfen. 
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Es erweist sich als vorteilhaft wenn der in die Struktur- 
information umzusetzende Code, also die durch den Compiler 
Oder auf andere Art und Weise erzeugten Maschinenbef ehle nur 
bestimmte Maschinenbef ehl-Typen, namlich unkondit ionierte Be- 
5 fehle, kondit ionierte Befehle, Predicate-Bef ehle , und Loop- 
Befehle umfassen. Dann lassen sich in der Kegel besonders 
lange (besonders viele Befehle enthaltende) Bef ehls-Blocke 
mit nur einem Eintrittspunkt und nur einem Austritt spunkt 
bilden. Die Generierbar keit von moglichst langen Befehls- 

10 Blocken mit nur einem Eintrittspunkt und nur einem Austritts- 
punkt ist sehr bedeutsam, well sich Befehle, die ein- und dem 
^^0^- selben Bef ehls-Block angehoren, und zwar nur solche Befehle, 

als eine Einheit (als eine sich aus mehreren Befehlen zu- 
sammensetzende Makroinstruktion) behandeln lassen, die in 

15 eine gemeinsame Hardware-Block-St ruktur umgesetzt und auf ein 
Mai ausgefiihrt werden kann. Legt man der Konf igurierung eines 
Hardware-Blocks jeweils genau eine solche Einheit zugrunde 
(und ist der Hardware-Block groB genug, urn so konfiguriert 
werden zu konnen) , so lalit sich die Anzahl der zur Abarbei- 

20 tung eines Programms erf orderlichen Umstrukturierungen bzw. 

Umkonf igurierungen des Hardware-Blocks auf ein Minimum redu- 
zieren. Die Bef ehls-Blocke, deren Generierung derzeit favori- 
y\ siert wird, und deren Bildung durch die vorstehend genannten 

Bef ehlsgruppen auch moglich ist, sind die vorstehend bereits 
^25 erwahnten Hyperblocke. 



Hyperblocke zeichnen sich insbesondere dadurch aus, daft be- 
dingte Sprungbef ehle unter Anwendung der nachfolgend noch 
naher beschriebenen sogenannten if -Konversion eliminiert wer- 
30 den. 



Bezuglich weiterer Einzelheiten zu den Hyperblocken, anderen 
Bef ehls-Blocken und damit in Zusammenhang stehenden Themen 
wird auf 



35 
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- Wen-Mei W. Hwu et al.: "Compiler Technology for Future 
Microprocessors", Invited Paper in Proceedings of the IEEE, 
Vol. 83 (12), Dezember 1995, Special Issue on Micro- 
processors, Seiten 1625 bis 1640, 

5 

- Henk Neefs, Jan van Campenhout: "A Microarchitecture for a 
Fixed Length Block Structured Instruction Set Architec- 
ture", Proceedings of the Eighth lASTED International 
Conference on Parallel and Distributed Computing and 

10 Systems, Seiten 38 bis 42, lASTED/ACTA Press, 1996, und 

^i^^ - Richard H. Littin, J. A. David McWha, Murray W. Pearson, 

John G, Cleary: "Block Based Execution and Task Level 
Parallelism", in: John Morris (Ed.), "Computer Architecture 
15 98", Proceedings of the 3^"^ Australasian Computer Architec- 

ture Conference, ACAC'98, Perth, 2-3 February 1998, Austra- 
lian Computer Science Communications, Vol. 20, No. 4, Sei- 
ten 57 bis 66, Springer, Singapore, 

20 verwiesen. 

Die vorstehend erwahnten unkonditionierten Befehle sind Be- 
fehle zur bedingungslosen Bearbeitung von Oaten einschlieU- 
lich der Kopie von Daten von einem Speicherbereich in einen 

25 anderen (von einem Register in ein anderes) . Diese Befehle 
werden im folgenden als normale Befehle bezeichnet. Sie um- 
fassen arithmetische und logische Verknupf ungen zwischen 
Daten zu neuen Werten und die sogenannten Move-Befehle zur 
Kopie von Registerinhalten . Das allgemeine Format dieser Be- 

30 fehle lautet: <Mnemonic> <Ziel-Register>, <Quellen-Register 
1>, <Quellen-Register 2>. Zur Durchfuhrung der durch einen 
solchen Befehl spezif izierten Operation wird normalerweise 
eine arithmetische Einheit des Hardware-Blocks benotigt. 
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Die konditionierten Befehle sind Befehle zur Bearbeitung von 
Daten bei Voriiegen einer bestimmten Bedingung (Kondition) . 
Die durch diese Befehle auszuf uhrenden Aktionen entsprechen 
den durch die normalen Befehle ausfvihrbaren Aktionen, wobei 
5 die Ausflihrung der betreffenden Aktionen jedoch von einer 
vorbestimmten Bedingung abhangt . 1st die Bedingung erfullt, 
wird die durch den Befehl spezif izierte Aktion ausgefuhrt, 
anderenfalls wird nichts ausgefuhrt (der betreffende Befehl 
wirkt dann wie ein NOP-Befehl) . Diese Befehle werden im fol- 

10 genden als bedingte Befehle bezeichnet. Das allgemeine Format 
dieser Befehle lautet: <Mnemonic>p <Ziel-Register>, <Quellen- 
Register 1>, <Quellen-Register 2> <p-Flag>, wobei durch das 
"p" am Ende des Mnemonic die Abhangigkeit der Bef ehlsausf uh- 
rung von einer Bedingung signalisiert wird, und wobei die 

15 Bedingung durch einen bestimmten Zustand eines bestimmten 
Flags (des "p-Flag") definiert wird. Zur Durchfuhrung der 
durch einen solchen Befehl spezif izierten Operation wird 
normalerweise eine arithmetische Einheit des Hardware-Blocks 
benotigt; zur Oberprufung der Bedingung wird eine Vergleichs- 

20 Einheit benotigt, deren Ausgang mit dem Steuereingang der 
arithmetischen Einheit verbindbar ist. 

Die Predicate-Bef ehle sind Befehle zur Festlegung des Zustan- 
des des in den bedingten Befehlen verwendeten Bedingungs- 

25 Flags (des p-Flags) . Die Festlegung erfolgt dabei wahrend des 
Programmablauf s basierend auf einem Vergleich von zwei Daten. 
Diese Befehle werden im folgenden als pxx-Befehle bezeichnet. 
Das allgemeine Format dieser Befehle lautet: pxx <Quellen- 
Register 1>, <Quellen-Register 2>, <p-Flag>, wobei xx die 

30 durchzuf iihrende Vergleichsoperat ion spezifiziert und durch gt 
(grower als), ge (grofier oder gleich) , eq (gleich) , ne 
(ungleich) , le (kleiner oder gleich) oder It (kleiner als) zu 
ersetzen ist. Die pxx-Befehle sind mit den ublichen Branch- 
Befehlen vergleichbar und dienen zum Ersatz derselben durch 

35 die Anwendung der sogenannten if -Konversion (siehe hierzu den 
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vorstehend bereits erwahnten Aufsatz von Wen-Mei W. Hwu et 
al. ) . 

Die Loop-Befehle sind zur Schleif enwiederholung dienende 
5 Befehle am Ende eines Hyperblocks. Sie veranlassen einen 

Rucksprung an den Anfang des betreffenden Hyperblocks, falls 
eine im Befehl spezif izierte Bedingung erfullt ist; sie kon- 
nen die Generierung eines READY-Signals veranlassen, wenn die 
Bedingung nicht mehr erfullt ist. Die Bedingung ist durch ein 
10 bestimmtes Ergebnis einer Vergleichsoperation definiert. Das 
allgemeine Format dieser Befehle lautet: loopxx <Quellen- 
Register !>, <Quellen-Register 2>, wobei xx die durchzu- 
fuhrende Vergleichsoperation spezif iziert . 

15 Wie aus den Formaten der genannten Befehlstypen ersichtlich 
ist, werden als Daten- und/oder Signalquellen und Daten- 
und/oder Signalziele jeweils Register verwendet. Dies erweist 
sich bei Verwendung von Hardware-Blocken nach Art der Figur 
12 als besonders vorteilhaft, well auf die Register (das 

20 register file 44) besonders effizient zugegriffen werden 

kann. Prinzipiell konnten aber auch Befehle zugelassen wer- 
den, deren Daten- und/oder Signalquellen und Daten- und/oder 
Signalziele keine Register sind. 

25 Viele Programme oder wenigstens grofte Telle von diesen konnen 
unter ausschliefllicher Verwendung der vorstehend erlauterten 
Bef ehls-Typen geschrieben oder in solche Programme iibersetzt 
werden und mithin vollstandig in einen Hardware-Block der in 
der Figur 12 gezeigten Art zur Ausfuhrung gebracht werden. 

30 Die Verwendung derartiger Hardware-Blocke in programm- 

gesteuerten Einheiten kann deren Leistungsf ahigkeit daher 
erheblich steigern. Hardware-Blocke der in der Figur 12 ge- 
zeigten Art konnen jedoch auch aulierhalb programmgesteuerter 
Einheiten als eigenstandige Einrichtungen zum Einsatz kommen 
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und dann ebenfalls basierend auf Befehlen oder Bef ehlsstromen 
konfiguriert warden. 

Im folgenden wird nunmehr die Konf igurierung eines Hardware- 
Blocks beschrieben, durch welche dieser durch Befehle oder 
Bef ehlsf olgen vorgegebene arithmetische und/oder logische 
Operationen oder Operationsf olgen ausfuhren kann. 

Der Hardware-Block, genauer gesagt dessen Teileinheiten 
(arithmetische Einheiten, Vergleichs-Einheiten, Multiplexer, 
Demultiplexer . . . ) und die Verbindungen zwischen den Teil- 
einheiten werden im betrachteten Beispiel durch die ge- 
wunschte Konf igurat ion reprasentierenden Konf igurations-Daten 
(Konf igurations-Bits) konfiguriert. Dementsprechend ist es 
die Aufgabe des nachfolgend beschriebenen Konf igurations- 
Verfahrens, die Konf igurations-Daten bzw. einen diese ent- 
haltenden Bitstrom basierend auf den der Hardware-Block- 
Konf iguration zugrundezulegenden Befehlen oder Bef ehlsf olgen 
zu generieren oder zu variieren. 

Im betrachteten Beispiel wird davon ausgegangen, dafi aus- 
schliefilich die vorstehend genannten Typen von Befehlen, d.h. 
normale Befehle, bedingte Befehle, pxx-Befehle und loopxx- 
Befehle umgesetzt werden; andere Befehle mussen anderweitig 
ausgefuhrt werden, beispielsweise durch die Ausfuhrungs- 
einheit einer herkommlichen programmgesteuerten Einheit. 

Fur die Umsetzung der umsetzbaren Befehle in entsprechende 
Hardware-Block-Strukturen kann es sich als vorteilhaft erwei- 
sen, wenn die Befehle von Haus aus ein in den Figuren lA 
(normale Befehle), IB (bedingte Befehle), IC (pxx-Befehle) , 
und ID (loopxx-Bef ehle) beispielhaft veranschaulichtes ein- 
heitliches Format aufweisen oder durch einen Decodierer in 
ein solches Format gebracht werden. 
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Insbesondere wenn die Teileinheiten des Hardware-Blocks 
konf igurierbar sind, werden diesen (physikalischen) Teil- 
einheiten logische bzw. virtuelle Einheiten zugeordnet, wobei 
die virtuellen Einheiten die verschiedenen Funktionen der 
physikalischen Teileinheiten angeben . Der physikalischen 
Teileinheit "erste arithmetische Einheit AUl" konnen - sofern 
diese konf igurierbar ist - beispielsweise die virtuellen Ein- 
heiten Addierer, Subtrahierer etc. zugeordnet sein. Eine 
virtuelle Einheit ist genau einer physikalischen Teileinheit 
zugeordnet, aber einer physikalischen Teileinheit konnen 
mehrere virtuelle Einheiten zugeordnet sein. Samtliche vir- 
tuellen Einheiten werden vorzugsweise in einer Tabelle oder 
Liste verwaltet. Die jeweiligen Eintrage enthalten neben 
Informationen zu den virtuellen Einheiten selbst auch Infor- 
mation daruber, welcher physikalischen Teileinheit die jewei- 
ligen virtuellen Einheiten zugeordnet sind, uber welche 
Konf igurations-Bits und wie diese physikalische Teileinheit 
gegebenenf alls konfiguriert werden muft, um ihr die durch die 
virtuelle Einheit reprasentierte Funktion. zu verleihen. 

Vorzugsweise wird ein kompletter Hyperblock in eine Hardware- 
Block-Struktur umgesetzt . 

Die Umsetzung eines Befehls in eine Hardware-Block-Struktu- 
rierungsinf ormationen erfolgt im wesentlichen in drei Phasen. 

In der ersten Phase wird zunachst ermittelt, welcher Typ von 
virtueller Einheit (Addierer, Subtrahierer, Mult iplizierer 
. . . ) zur Ausfuhrung der betref fenden Instruktion benotigt 
wird, und ob eine solche virtuelle Einheit noch verfugbar 
ist. Ist noch eine virtuelle Einheit des benotigten Typs 
frei, so wird diese oder eine von diesen zur Ausfuhrung der 
betref fenden Instruktion ausgewahlt. Sodann erfolgen die Kon- 
figuration oder deren Vorbereitung und eine Reservierung der 
der ausgewahlten virtuellen Einheit zugeordneten physikali- 
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schen Teileinheit. Zur Konf igurat ion werden einfach die der 
betreffenden physikalischen Teileinheit zugeordneten Konfigu- 
rations-Bits gesetzt oder zuruckgesetzt ; dies bereitet keine 
Schwierigkeiten, denn die Inf ormationen, welcher physikali- 
schen Teileinheit die ausgewahlte virtuelle Einheit zugeord- 
net ist, iiber welche Konf igurations-Bits und wie diese physi- 
kalische Teileinheit gegebenenf alls zu konf igurieren ist, 
werden ja zusammen mit der virtuellen Einheit verwaltet . Die 
Reservierung der der ausgewahlten virtuellen Einheit zugeord- 
neten physikalischen Teileinheit ist notwendig, urn zu verhin- 
dern, dai2> die betreffende physikalische Teileinheit mehrfach 

verwendet werden kann. Im betrachteten Beispiel wird dies 

t 

dadurch bewerkstelligt , dali nach jeder Vergabe einer physi- 
kalischen Teileinheit fur einen bestimmten Zweck samtliche 
virtuellen Einheiten, die der betreffenden physikalischen 
Teileinheit zugeordnet sind, gesperrt werden. 

Bei pxx-Befehlen kann es je nach dem Aufbau des Hardware- 
Blocks erforderlich sein, abhangig vom p-Flag eine ganz be- 
stimmte physikalische Teileinheit (Vergleichs-Einheit ) aus- 
zuwahlen . 

Bei bedingten Befehlen wirkt sich das p-Flag nur dann auf die 
Auswahl der virtuellen/physikalischen Einheit (en) aus, wenn 
bestimmte Instruktionen nur mit bestiminten Flags moglich 
sind, also keine vollstandige Orthogonalitat in dem Teil- 
befehlssatz fur bedingte Befehle vorhanden ist. 

In der zweiten Phase der Hardware-Block-Konf igurierung werden 
die den ausgewahlten physikalischen Teileinheiten vor- 
und/oder nachgeschalteten Multiplexer konf iguriert , urn die 
Daten- und/oder Signalquellen und die Daten- und/oder Signal- 
ziele entsprechend den Festlegungen in den umzuset zenden 
Instruktionen einzustellen . Die Multiplexer und das Format 
der umzusetzenden Instruktionen sind im Idealfall so anein- 
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ander angepaftt, daft die die Daten- und/oder Signalquellen und 
die die Daten- und/oder Signalziele festlegenden Teile der 
Instruktionen unverSndert als die die Multiplexer konfigurie- 
renden Konf igurations-Bits ubernommen werden konnen. 1st dies 
- aus welchem Grund auch immer - nicht moglich, konnen die 
die Multiplexer, konf igurierenden Konf igurations-Bits bei- 
spielsweise einer Tabelle entnommen werden, in welcher die 
Zuordnung zwischen den die Daten- und/oder Signalquellen und 
die Daten- und/oder Signalziele festlegenden Teilen der 
Instruktionen und den die Multiplexer konf igurierenden Kon- 
f igurations-Bits gespeichert ist. Die Konf igurierung, die 
erforderlich ist, urn eine Verbindung zu einer bestimmten 
Daten- und/oder Signalquelle und/oder zu einem bestimmten 
Daten- und/oder Signalziel herzustellen, ist vorzugsweise fur 
alle Multiplexer gleich, 

Eine gesonderte Behandlung ist notwendig, wenn die der aus- 
zufuhrenden Operation zugrundezulegenden Daten zumindest 
teilweise aus einer im Instrukt ions-Code enthaltenen Kon- 
stanten bestehen, Dann muB 

- ein freies (Konstanten-) Register gesucht werden, 

- dieses Register als Daten- und/oder Signalquelle verwendet 
werden, und 

- die im Instruktions-Code enthaltene Konstante vor der 
Inbetriebnahme des UCB in das ausgewahlte Register ein- 
geschrieben werden. 

Im betrachteten Beispiel wird vorab (iberpriift, ob die be- 
treffende Konstante schon in einem (Konstanten- ) Register 
gespeichert ist. Ergibt sich dabei, daft bereits ein die Kon- 
stante enthaltendes (Konstanten-) Register existiert, so wird 
dieses schon existierende (Konstanten-) Register als Daten- 
und/oder Signalquelle verwendet. 
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Zu beachten ist ferner, daft die umzuset zenden Instruktionen 
unterschiedlich viele Daten- und/oder Signalquellen und 
Daten- und/oder Signalziele aufweisen und/oder von Bedingun- 
gen abhangen und insofern eine Sonderbehandlung der einzelnen 
Instruktionen erforderlich ist. 

Als Daten- und/oder Signalziel verwendete Register werden 
ubrigens als belegt markiert, da innerhalb eines Hyperblocks' 
keine Zweitbelegung zulassig ist und durch ein sogenanntes 
(Runtime) Register Renaming, einer aus superskalaren Archi- 
tekturen bekannten Technologie, verhindert werden mufi , 

Nach dieser (fur alle Befehle gemeinsamen) zweiten Phase wer- 
den fur einzelne Befehlstypen spezielle Teilschritte einge- 
fugt, die sich aus den jeweiligen Besonderheiten ergeben. 

Unter anderem mufi bei bedingten Befehlen die das Vorliegen 
der Bedingung uberprufende Vergleichs-Einheit ermittelt wer- 
den und deren Ausgangssignal uber den zugehorigen Demulti- 
plexer auf die die Operation ausfuhrende arithmetische 
Einheit geschaltet werden. Ferner ist zu beriicksichtigen, 
welcher Art die Bedingung ist. 

Bei bedingten Move-Bef ehlen ist zusatzlich dafur Serge zu 
tragen, daft der Inhalt des Zielregisters bei Nicht-Ausf uhrung 
des Befehls nicht verandert wird. 

Nach der zweiten Phase der Hardware-Block-Konf igur ierung 
konnte diese beendet und der Hardware-Block gestartet werden. 
Dies geschieht vorzugsweise jedoch erst nach der Ausfuhrung 
der nachfolgend beschriebenen dritten Phase. 

In dieser dritten Phase der Hardware-Block-Konf igurierung 
wird ein sogenanntes data forwarding realisiert. Dabei werden 
als Daten- und/oder Signalquellen nicht stur die in den In- 
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struktionen angegebenen Daten- und/oder Signalquellen verwen- 
det, sondern nach Moglichkeit die physikalische Teileinheit, 
die die betreffende Daten- und/oder Signalquelle innerhalb 
des jeweiligen Hyperblocks zuvor zu beschreiben hatte. Dies 
erweist sich in zweifacher Hinsicht als vorteilhaft: einer- 
seits, weil eventuell weniger Register benotigt werden (wenn 
die in der Instruktion angegebene Daten- und/oder Signal- 
quelle nicht als solche verwendet wird, muft sie auch nicht 
beschrieben werden und kann gegebenenf alls ganz weggelassen 
werden), und andererseits, weil die benotigten Daten bei Ab- 
holung von der diese erzeugenden Teileinheit (beispielsweise 
einer arithmetischen Einheit) fruher verfugbar sind als wenn 
sie zuerst in ein Register geschrieben und von dort abgeholt 
werden mussen. Das data forwarding kann bei alien Befehlen 
zur Anwendung kommen und erweist sich im Durchschnitt als 
enormer Vorteil. 

Das soeben kurz in Worten beschriebene Verfahren lafit sich 
auch durch dessen sof twaremafiige und dessen hardwaremaJiige 
Realisierungsmoglichkeiten und in mathematischer Notation 
veranschaulichen . 

Zunachst soil eine sof twaremaftige Realisierung in einer C+-h- 
ahnlichen Darstellung beschrieben werden. Im betrachteten 
Beispiel erfolgt die Verwaltung der Inf ormationen zu den 
Hardware-Block-Konf igurationsdaten durch Klassen. 

Die Klasse fur eine virtuelle Einheit wird im betrachteten 
Beispiel f olgenderma/ien definiert: 

class clVirtualUnit { 

private: unsigned int uiPhysicalPartNumber ; 
unsigned int uiMnemonicType; 
BOOL bIsConfigurable; 
unsigned int uiConfBits; 
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unsigned int uiConf Bitslndex; 
BOOL bTwoSourceRegs; 

unsigned int uiSrcMultiplexNumber [2 ] ; 

unsigned int uiSrcMultiplexIndex [2 ] ; 

BOOL bDestinationReg; 

unsigned int uiDestMultiplexNumber ; 

unsigned int uiDestMultiplexIndex; 

BOOL bIsUsed; 

BOOL bSecondPIsused; 

BOOL bIsConstantRegister; 

unsigned int uiConstantlndex; 

unsigned int uiConstantValue; 

public: unsigned int uiGetPartNumber ( void ); 

unsigned int uiGetMnemonicType ( void ); 
BOOL bIsUnitConf igurable ( void ); 
unsigned int uiGetConf Bits ( void ) ; 
unsigned int uiGetConf Bitslndex ( void ); 
BOOL bHasTwoSourceRegs ( void ); 
unsigned int uiGetSrcMult iplexNumber 

( unsigned int ) ; 
unsigned int uiGetSrcMultiplexIndex 

( unsigned int ) ; 
BOOL bHasDestinationReg ( void ); 
unsigned int uiGetDestMultiplexNumber ( void 
unsigned int uiGetDestMultiplexIndex ( void 
void vFreePart ( void ) ; 
BOOL bMarJcUsedPart ( void ) ; 
BOOL bMarkSecondUsedFlag { void ); 
BOOL bGetIsUsed( void ); 
BOOL bGetlsUsedSecondFlag ( void ); 
BOOL bIsConstantRegister ( void ); 
BOOL bSetConstantValue ( void ); 
unsigned int uiGetConstantValue ( void ); 
unsigned int uiGetConstant Index ( void ); 
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} 



Die in der Klasse enthaltenen Daten und Methoden dienen zur 
Modellierung einer Mikroarchitektur . 

Von den Daten bedeuten: 

uiPhysicalPartNumber : Diese Variable enthalt eine eindeutige 
Nummer fur die physikalische Teileinheit innerhalb des 
Hardware-Blocks . 

uiMnemonicType: Diese Variable enthalt in codierter Form den 
Verknupfungstyp, der zu der jeweiligen virtuellen Ein- 
heit gehort. 

bIsConf igurable: Dieses Flag zeigt an, ob die zugehorige phy- 
sikalische Teileinheit konfiguriert werden mufi, urn diese 
virtuelle Einheit zu erhalten. 

uiConfBits: Falls bIsConf igurable TRUE ist, werden hier 
die zugehorigen Konf igurationsbit s gespeichert, urn die 
physikalische Teileinheit fur exakt diese Funktion zu 
konf igurieren . 

uiConfBitsIndex: Falls bIsConf igurable == TRUE ist, wird der 
Index zur Speicherung der Konf igurationsbits im Bitstrom 
an dieser Stelle gespeichert. 

bTwoSourceRegs: Dieses Flag wird auf TRUE gesetzt, falls fur 
den betreffenden Befehl zwei Sourceregister angegeben 
werden mussen, ansonsten auf FALSE. 

uiSrcMultiplexNumber [2] : Bei zwei Sourceregistern werden die 
physikalischen Numinern der zugehorigen Multiplexer in 
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dieser Variablen gespeichert, gegebenenf alls ist nur die 
Variable mit dem Index 0 gultig. 

uiSrcMultiplexIndex [2] : Hier warden die Indizes der Multi- 
plexer fur die Sourceregister gespeichert. 

bDestinationReg: Dieses Flag wird auf TRUE gesetzt, falls fur 
den betreffenden Befehl ein Destinationregister (nicht - 
flag!) angegeben werden muIJ, ansonsten auf FALSE. 

uiDestMultiplexNumber : Hier wird die physikalische Nummer des 
zugehorigen Multiplexers fur das Zielregister gespei- 
chert . 

uiDestMultiplexIndex: Hier wird der Index des Multiplexer fur 
das Destinationregister gespeichert. 

bIsUsed: In diesem Flag wird gespeichert, ob diese virtuelle 
(und damit zugleich die physikalische) Teileinheit be- 
nutzt wurde. Ein Setzen dieses Flags auf TRUE bedeutet, 
daii diese Teileinheit nicht mehr genutzt werden kann 
(aulier bei den bedingten Move-Bef ehlen (movep) ) . 

bSecondPIsUsed: Flir den Sonderfall der movep-Bef ehle wird in 
diesem Flag die zweite Nutzung eines p-Flags einschliefi- 
lich des Vergleichs gespeichert. Sind bIsUsed und 
bSecondPIsUsed auf TRUE gesetzt, ist der dynamische 
Wegmultiplexer (AU) , auf den ein movep-Befehl abgebildet 
wird, zur weiteren Nutzung gesperrt. 

bIsConstantRegister: Dieses Flag zeigt an, dafi die physikali- 
sche Teileinheit einem Konstantenregister entspricht 
(TRUE) Oder nicht (FALSE). 
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uiConstant Index : Im Fall eines Konstantenregisters muft der 

Wert der Konstanten, der gespeichert und genutzt: werden 
soil, im Bitstrom eingetragen werden. In diesem Fall ist 
der Index im Bitstrom in dieser Variablen gespeichert. 

5 

uiConstantValue : Der Wert, der im Konstantenregister gespei- 
chert wird, wird fur weitere Vergleiche zusatzlich in 
dieser Variablen der Instanz gespeichert. 



10 Die in einer Instanz dieser Klasse auftretenden Variablen 

miissen alle zum Zeitpunkt des Starts der Konf iguration belegt 

y werden. Hierzu werden hier nicht explizit aufgefuhrte Metho- 
den benutzt, die im Konstruktor einer nachfolgend erlauterten 
Configurable-Block- bzw. CB-Klasse genutzt werden, um alle 

15 fiir die Umsetzung notwendigen Inf ormationen in die Instanz zu 
schreiben und zugleich die Flags bIsUsed und bSecondPIsUsed 
auf FALSE zu setzen. Wahrend der Lebenszeit dieser Instanz 
andern sich dann nur noch diese beiden Flags, die uber vor- 
definierte Methoden mit dem Wert TRUE bzw. FALSE belegbar 

20 sind, sowie - im Fall eines Konstantenregisters - die 

Variable uiConstantValue, in der der aktuelle Wert des Regi- 
sters fur weitere Vergleiche zwischengespeichert wird. 

Von den Methoden der vorstehend definierten Klasse fur die 
25 virtuellen Einheiten bedeuten: 



unsigned int uiGet PartNumber ( void ): Diese Methode gestattet 
den lesenden Zugriff auf die Nummer der zur virtuellen 
Teileinheit gehorenden physikalischen Teileinheit; die 
30 Nummer wird als Riickgabewert zuriickgelief ert . 

unsigned int uiGetMnemonicType ( void ): Diese Methode gestat- 
tet den lesenden Zugriff auf Mnemonic, der in der vir- 
tuellen Einheit implement iert werden kann. 



35 
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BOOL bIsUnitConf igurable ( void ): Diese Methode liefert TRUE, 
falls die physikalische Teileinheit konfiguriert werden 
mufii . Unter diesen Umstanden sind die Eintrage in uiConf- 
Bits und uiConf Bitslndex giiltig und konnen mit den fol- 
genden Methoden uiGetConf Bit s ( ) und uiGetConf Bitslndex ( ) 
erhalten werden. Ferner miissen alle anderen virtuellen 
Teileinheiten, die zur gleichen physikalischen Einheit 
gehoren, ebenfalls gesperrt werden. Fiir den Riickgabewert 
FALSE hingegen sind virtuelle und physikalische Einheit 
identisch. 

unsigned int uiGetConf Bits ( void ) : Durch diese Methode wer- 
den die Konf igurationsbits gelesen und als Riickgabewert 
zuruckgelief ert , Diese Werte sind nur giiltig, wenn 
bIsConf igurable den Wert TRUE besitzt. 

unsigned int uiGetConf Bitslndex ( void ): Durch diese Methode 
wird der Index im Bitstrom fiir die Konf igurationsbits 
gelesen und als Riickgabewert zuriickgelief ert . Dieser 
Wert ist nur gultig, wenn bIsConf igurable den Wert TRUE 
besitzt . 

BOOL bHasTwoSourceRegs ( void ) : Ein Auf ruf dieser Methode 
liefert den Wert TRUE, falls diese Operation zwei 
Sourceregister besitzt und diese in die entsprechenden 
Multiplexer einzutragen sind^ ansonsten den Wert FALSE. 

unsigned int uiGetSrcMultiplexNumber ( unsigned int ): Diese 
Methode liefert die Nummer der physikalischen Teil- 
einheit, die den Multiplexer fur die Sourceregister dar- 
stellt. Auf ruf parameter ist der Index in dem Array von 2 
Eintragen, wobei der Index 1 nur giiltige Werte liefert, 
falls das Flag bHasTwoSourceRegs den Wert TRUE besitzt. 
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unsigned int uiGetSrcMultiplexIndex ( unsigned int ): Diese 
Methode liefert den Index zum Eintrag in den Bitstrom, 
um die Konf igurierung des Multiplexers fur die Source- 
register vornehmen zu konnen. Aufruf parameter ist der 
Index in dem Array von 2 Eintragen, wobei der Index 1 
nur gultige Werte liefert, falls das Flag bHasTwoSource- 
Regs den Wert TRUE besitzt. 

BOOL bHasDestinationReg( void ): Ein Aufruf dieser Methode 

liefert den Wert TRUE, falls diese Operation ein Desti- 
nationregister besitzt und dies in den entsprechenden 
Multiplexer einzutragen ist, ansonsten den Wert FALSE. 

unsigned int uiGetDestMultiplexNumber ( void ): Diese Methode 
liefert die Nummer der physikalischen Teileinheit, die 
den Multiplexer fur das Dest inationregister darstellt. 
Der Ruckgabewert ist nur gultig, falls das Flag bHas- 
DestinationReg den Wert TRUE besitzt. 

unsigned int uiGetDestMultiplexlndex ( void ): Diese Methode 
liefert den Index zum Eintrag in den Bitstrom, um die 
Konf igurierung des Multiplexers ftir das Destination- 
register vornehmen zu konnen. Der Ruckgabewert ist nur 
gultig, falls das Flag bHasDestinat ionReg den Wert TRUE 
besitzt . 

void vFreePart ( void ) : Diese Methode loscht alle Belegungs- 
flags, indem diese mit dem Wert FALSE belegt werden. 
Hierin erfolgt also ein schreibender Zugriff auf die 
Flags. 

BOOL bMarkUsedPart ( void ): Das Belegtflag bIsUsed wird uber 
diese Methode auf TRUE gesetzt. Ruckgabewert ist TRUE, 
falls die Operation erfolgreich war, FALSE, falls dieses 
Element bereits belegt war. 
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BOOL bMarkSecondUsedFlag( void ): Das zweite Belegtflag 

bSecondPIsUsed wird entsprechend auf TRUE gesetzt . Ruck- 
gabewert ist auch hier TRUE, falls die Operation erfolg- 
reich war, FALSE, falls dieses Element bereits belegt 
war . 



BOOL bGetIsUsed( void ): Diese Methode liefert als Ruckgabe- 
wert den Wert der Variablen bIsUsed. 

BOOL bGetIsUsedSecondFlag( void ): Diese Methode liefert als 
Ruckgabewert den Wert der Variablen bSecondPIsUsed. 

BOOL bIsConstantRegister( void ): Diese Methode gibt TRUE zu- 
ruck, falls die virtuelle Teileinheit einem Konstanten- 
register entspricht, ansonsten FALSE. 

BOOL bSetConstantValue( void ): Mit Hilfe dieser Methode kann 
der aktuelle Konstantenwert in der Variablen uiConstant- 
Value gespeichert werden, falls diese virtuelle Einheit 
einem Konstantenregister entspricht und dieses bisher 
noch nicht belegt wurde. Ruckgabewert ist TRUE fur Er- 
folg, FALSE sonst . 

unsigned int uiGetConstantValue ( void ): Mit Hilfe dieser 

Methode wird der gespeicherte Konstantenwert zuruckgege- 
ben . 

unsigned int uiGetConstant Index ( void ): Der Index in den 
Bitstrom, der fur die Speicherung des Konstantenwert s 
dort notwendig ist, wird uber diese Methode erhalten. 

Fur die Modellierung eines Hardware-Blocks (CBs) wird eine 
zweite Klasse definiert, die u.a. Instanzen der Klasse 
clVirtualUnit sowie weitere Variablen und Methoden enthalt. 
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Zur Vereinf achung wird eine Speicherung der Elemente in einem 
statischen Array angenommen; eine verkettete Lists ist natur- 
lich ebenfalls denkbar. Es sei an dieser Stella angemerkt, 
dali fur die hier angegebenen Klassen nur ein Teil der Metho- 
den dargestellt wird. 

class clCB 
{ 

private: BITFIELD *clbitfield; 

class clVirtualUnit clArrayVirtualUnits 

[NUM_OF_PARTS] ; 

public : clCB ( ) ; 

void vSetupBitf ield( BITFIELD 

void vFreeAll ( void ) ; 

BOOL bDoAllPhase_l__Parts 

( unsigned int, BITFIELD * ) 

BOOL bDoCommonPhase_2_Parts ( unsigned int, 

BITFIELD 
unsigned int, 
unsigned int, 
unsigned int ) ; 

void vDataForwarding ( unsigned int, unsigned int ); 

void vCopyBitf ield ( BITFIELD *, BITFIELD * ); 

unsigned int uiGetMuxCode ( unsigned int, 

unsigned int ) ; 

unsigned int uiGetRegPartNumFromCode 

( unsigned int ) ; 

unsigned int uiGetPartNumFromFlag 

( unsigned int ) ; 

unsigned int uiGet IndexFromNum ( unsigned int ); 

unsigned int uiGetPartNumFromBit field 

( unsigned int ) ; 

void vSetBitfield( unsigned int, unsigned int, 

unsigned int ) ; } ; 
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Die Variablen und Methoden der Klasse clCB bedeuten im ein- 
zelnen : 

BITFIELD *clBitfield: Diese Variable entspricht dem zu gene- 
rierenden Bitstrom fiir eine Lauf zeit konf iguration des 
CB. 

class clVirtualUnit clArrayVirtualUnits [NUM_OF_PARTS ] : Diese 
Array von Instanzen der Klasse clVirtualUnit enthalt 
alle Inf ormationen fur alle virtuellen Einheiten und 
somit auch fiir alle physikalischen Teileinheiten . 

clCB(): Dieser Konstruktor wurde aufgefiihrt, urn zu verdeutli 
Chen, worin die Aufgaben dieser Klasse bestehen. In 
einer Startphase mussen sowohl das Bitfeld als auch all 
Instanzen der Klasse clVirtualUnit, die im Array 
clArrayVirtualUnits [] zusammengef aJit werden, ini- 
tialisiert werden. Zur Initialisierung der Klassen- 
instanzen zahlen insbesondere das Beschreiben aller 
Konf igurationsdaten sowie das Rucksetzen aller Flags, ui 
in der Betriebsphase auf die notwendigen Daten lesend 
zugreifen zu konnen. 

void vSetupBitf ield ( BITFIELD ^ ) : In dieser Methode wird da 
Bitfeld mit alien Vorbelegungen versorgt. 

void vFreeAll( void ): Diese Methode wird zum Loschen aller 
Belegtflags in dem Array clArrayVirtualUnits [ ] aufgeru- 
f en . 

BOOL bDoAllPhase_l_Parts (unsigned int, BITFIELD * ) : In die- 
ser Methode sind alle Telle zur Phase 1 zusammengef alit . 
Sie wird aufgerufen, nachdem eine freie Teileinheit zur 
Aufnahme des Mnemonics gefunden wurde und enthalt die 



GR 98 P 8109 



32 

Markierung aller zugehorigen virtuellen Einheiten als 
besetzt, Bestimmung der Konf igurationsbit s und des Index 
in den Bitstrom und Eintragung in einen temporaren 
Bitstrom. Parameter sind der Index in dem Array der vir- 
5 tuellen Einheiten und der Zeiger auf den temporaren 

Bitstrom. Der Riickgabewert TRUE zeigt eine erfolgreiche 
Phase 1 an, FALSE den Milierfolg (etwa durch nicht aus- 
reichende Net zressourcen) , 

10 BOOL bDoCommonPhase__2_Parts ( unsigned int, BITFIELD 

unsigned int, unsigned int, unsigned int) : Diese Methode 
\ falit die fiir alle Bef ehlsgruppen gemeinsamen Methoden 

zusammen. Hierzu zahlen die Eintrage fiir die Source- und 
Destinationregister einschliefilich der Behandlung der 

15 Konstanten als Eingabewerte . Riickgabewert ist TRUE fiir 

Erfolg und FALSE fur Milierf olg . 



void vDataForwarding ( unsigned int,. unsigned int): Die Be- 
rechnung des Data Forwarding mit alien zugehorigen 
20 Methoden ist in dieser Methode integriert. Die Vor- 

gehensweise betrifft die Sourceregister , deren physika- 
lische Nummer in den Parametern ubergeben werden. Unter 
^ Nutzung weiterer Methoden wird ermittelt, ob ein Source- 

^ register bereits ein fruheres Destinationregister war. 

25 Ist dies der Fall, wird die letzte berechnende AU aus 

dem Bitstrom ermittelt und anstelle des Registers ein- 
getragen . 



void vCopyBitf ield ( BITFIELD BITFIELD Diese Methode 

30 verkniipft die Eintragung in dem zweiten Bitstrom mittels 

ODER mit denen des ersten und speichert das Ergebnis im 
ersten Bitstrom. Hierdurch wird das temporare Zwischen- 
ergebnis im zur spateren Konf iguration berechneten 
Bitstrom gespeichert . 

35 



GR 98 P 8109 



33 

unsigned int uiGetMuxCode (unsigned int, unsigned int) : Diese 
Methode berechnet die Konf igurationsbits, die fur einen 
Multiplexer in den Bitstrom zu laden sind, um als Quelle 
eine physikalische Teileinheit auszuwahlen. Parameter 
dieser Methode sind die physikalische Nummer des Multi- 
plexers sowie der Quelleinheit . Diese Methode ist un- 
bedingt notwendig zur Konfiguration, da in der Beschrei- 
bung der virtuellen Einheiten zwar der Index des Ein- 
trags, nicht jedoch der Eintrag selbst gespeichert wird. 
Diese Methode kann fUr ein vollstandiges Netzwerk als 
tabellengestutzte Umrechnung gegebenenf alls ohne Beruck- 
sichtigung der Multiplexernummer implementiert sein, da 
in diesem Fall alle Multiplexer auf einheitliche Weise 
konfigurierbar sind. Fur partielle Netzwerke mufi hier 
gro/ierer Aufwand betrieben warden, insbesondere kann 
eine Vernetzung unmoglich sein. Riickgabewert sind die 
Konfigurationsbits im Erfolgsfall bzw. eine sonst un- 
• genutzte Codierung fur den Fall des MiUerfolgs. 

unsigned int uiGetRegPartNumFromCode (unsigned int): Diese 
Methode berechnet die Nummer der Teileinheit aus dem 
Code in der Instruktion. Dies kann naturgemaft nur fur 
Register erfolgen, wobei im Fall einer Konstanten die 
beschriebene Vorgehensweise in dieser Methode integriert 
ist, die zur Speicherung der Konstanten und zur Ruckgabe 
der physikalischen Nummer des Konstantenregisters f iihrt . 
Riickgabewerte sind die Nummer der Teileinheit im Er- 
folgsfall, ansonsten eine nicht benutzte Kennung fur den 
MiBerfolg. 

unsigned int uiGetPartNumFromFlag (unsigned int): Fur die Um- 
rechnung einer Flagnummer in die Nummer der physikali- 
schen Teileinheit ist diese Methode zustandig. Aufruf- 
parameter ist das p-Feld in dem Instruktionsf ormat , 
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Ruckgabewert die Teileinheitsnummer oder eine besondere 
Kennung im Fall des Mifierfolgs. 

unsigned int uiGetlndexFromNum (unsigned int) : Mit Hilfe die- 
ser Methode wird der Index in den Bitstrom fiir eine 
Teileinheit mit bekannter physikalischer Nuininer (als 
Parameter) berechnet und zuriickgegeben . Diese Berechnung 
kann in Tabellenform erfolgen. 

unsigned int uiGetPartNumFremBilfield (unsigned int): Diese 
Methode liest den Eintrag in dem Bitfeld an dem als 
Parameter ubergebenen Index und rechnet die erhaltene 
Konfigurationsmaske in die physikalische Nummer der 
Teileinheit zuruck, die als Ergebnis zuruckgegeben wird. 
uiGetPartNumFromBitfield wird im Data Forwarding ein- 
gesetzt, wo der Datenweg von einem fruheren Zielregister 
auf die das Ergebnis bestimmende Teileinheit zuruck- 
verfolgt wird, damit die Daten vorzeitig verwendbar 
sind. 



void vSetBitfield( unsigned int, unsigned int, unsigned int): 
Diese Methode wird mit drei Parametern aufgerufen: Der 
Index der Eintrags, die Lange des Eintrags und die 
Maske. Der Aufruf bewirkt den Eintrag in dem Bitfeld an 
der entsprechenden Stelle. 

Mit den vorstehend genannten und erlSuterten Variablen und 
Methoden ergibt sich folgender Pseudocode fiir das Verfahren 
zur der auf Befehlen oder Bef ehlsf olgen basierenden Konfigu- 
rierung eines Hardware-Blocks der in der Figur 12 dargestell- 
ten Art (fiir die struktur-prozedurale Programmierung) : 



unsigned int k; 

BITFIELD *clTempBitfield; 
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// 1. Phase: Bestimmung einer physikalischen Teileinheit 2ur 
// Aufnahme der Ver kniipf ung . 
// mnenomic in uiMem stehend 

5 vSetupBitf ield( clTempBitf ield ); 

for( k = 0; k < NUM_OF_PARTS; k+4- ) 
{ 

if ( clArrayVirtualUnits [ k] : : uiGetMnenomic ( ) == uiMem 
10 && clArrayVitualUnit [k] : ibGetlsUsedO == FALSE ) 

break; 

if( k == NUM_OF_PARTS ) // Keine freie Verknupf ung gef unden 
15 return ( FALSE ) ; 

// Jetzt wird die freie Teileinheit als besetzt markiert, 

// gegebenenf alls eine Konf igurierung bestimmt und in diesem 

// Fall auch alle anderen virtuellen Einheiten als besetzt 

20 // markiert, Alle Maskenbits werden in einem temporaren 

// Bitstrom gespeichert. 



25 



if( bDoAllPhase_l_Parts ( k, clTempBitf ield ) == FALSE ) 
return ( FALSE ) ; 



// Nunmehr beginnt die zweite Phase: Fiir alle Instruktionen 

// werden die beiden/ gegebenenf alls ein Sourceregister 

// bestimmt und in den Bitstrom eingetragen. Entsprechendes 

// erfolgt mit dem Destinat ionregister , falls vorhanden. Die 

30 // entsprechenden Codierungen aus der Instruktion stehen in 

// den Variablen uiSourceRegl , uiSourceReg2 und uiDestReg, 

// wobei gegebenenf alls Konstanten als Quellen hier erkennbar 

// sind. 

35 if ( bDoPhase_2_CommonParts ( k, clTempBitf ield uiSourceRegl / 
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uiSourceReg2, uiDestReg == FALSE ) 
return ( FALSE ) ; 

switch ( uiMnemonicType ) 
{ 

case BEDINGTER_BEFEHL // p-Flag bestimmen, Eintrag fur CU 
case MOVEP_BEFEHL: // spez, erster Eintrag, 

// zweiter Eintrag moglich 

} 

vDoDataForwarding ( uiSourceRegl , uiSourceReg2 ); 

// Die letzte Aktion: Der temporar gespeicherte Bitstromcode 
// wird in den eigentlichen Bitstrom kopiert 

vCopyBitf ield ( clBitfield, clTempBitf ield ); 
return ( TRUE ) ; 

Die vorstehende zentrale Routine wird fur jede Instruktion, 
die ubersetzbar ist, aufgerufen. Ruckgabewert ist TRUE, falls 
die Umsetzung gelungen ist, ansonsten FALSE. Im letzteren 
Fall mufi die Instruktion im aufrufenden Programm behalten 
werden, da sie nicht eingefugt wurde, und der Bitstrom kann 
zur Ausfiihrung geladen werden. Das Ende einer Umsetzung wird 
also durch das Erschopfen der Ressourcen angezeigt oder durch 
eine nicht-ubersetzbare Instruktion wie beispielsweise einen 
Branchbef ehl erhalten . 

Wie vorstehend bereits erwahnt wurde, laftt sich die struktur- 
prozedurale Programmierung nicht nur sof twaremaftig, sondern 
auch hardwaremafiig realisieren. Eine mogliche Ausf uhrungsf orm 
einer hardwaremafiigen Realisierung wird nachfolgend unter Be- 
zugnahme auf die Figuren 2 bis 10 erlautert. Dabei wurde ver- 
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sucht, die einzelnen Phasen so weit wie moglich parallel 
durchlaufen zu lassen. 

Die bei der sof twaremSUigen Realisierung vorkommenden tabel- 
lengestiitzten Umrechnungen werden bei der hardwaremafJigen 
Realisierung als sogenannte Look-Up-Tables (LUTs) realisiert. 
LUTs sind dazu ausgelegt, im Ansprechen auf die Eingabe von 
Daten von diesen abhangende Daten auszugeben. Solche LUTs 
konnen beispielsweise durch ein EPROM oder eine andere 
Speichereinrichtung gebildet werden. Die eingegebenen Daten 
werden dann als Adresse verwendet, und die ausgegebenen Daten 
sind die unter dieser Adresse gespeicherten Daten. 

Fiir die erste Phase wird eine LUT der in der Figur 2 ver- 
anschaulichten Art verwendet. Diese LUT weist zwei Eingange 
(Address, Counter_Address) und vier Ausgange (Code, Comple- 
mentary, Counter_Up, No_Entry) auf. Die zwei Eingange dienen 
der Adressierung der LUT, wobei die tiber den einen Eingang 
(Address) zugefuhrten Daten und/oder Signale vom zu uber- 
setzenden Code abhangen, und wobei die uber den anderen 
Eingang ( Count er_Address ) zugefuhrten Daten und/oder Signale 
Zahlstande eines durch den Ausgang Counter_Up hochzahlbaren 
Zahlers ( Zahler-Arrays ) sind. Die Ausgange dienen zur Ausgabe 
des iibersetzten Codes (Code), von Signalen zum Hochzahlen des 
25 die Counter_Address generierenden Zahlers oder Zahler-Arrays 
(Counter_Up) , eines Signals zur Signalisierung fur den Fall, 
dali kein gtiltiger und freier Eintrag mehr vorliegt 
(No_Entry) , und eines ftir die Bearbeitung bedingter Move- 
Befehle (movep) benotigten Signals (Complementary), wobei 
sich der iibersetzte Code aus Konf igurations-Bits (Config- 
Bits), einem Konf igurat ionsindex (Config-Index) , undeiner 
Teilenummer (Part-Number) zusammenset zt . Die Look-Up-Table- 
Eintrage haben damit ftir den ersten Teil das in Figur 3A 
gezeigte Format. 



20 



30 
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10 



Der erwahnte zahler (das Zahler-Array ) wird als Markierungs- 
mittel (besetzt, schreibend) verwendet, wobei fur jeden 
Operations-Typen (Addition, Subtraktion . . . ) ein separater 
Zahler existiert. Der ZShlstand der Zahler gibt an, die 
wievielte Moglichkeit zur Ausfiihrung des zugeordneten 
Operations-Typs in Anspruch genommen werden kann. Die Tiefe 
der Zahler innerhalb dieses Zahler-Arrays hSngt von der An- 
zahl der Moglichkeiten zur Ausfuhrung der betreffenden 
Operation ab. Sind beispielsweise drei Additionsmoglichkeiten 
vorhanden, betragt die Zahlertiefe zwei Bit; in der korre- 
spondierenden LUT, die ja von dem Mnemonic-Code und dem 
Zahlerstand adressiert wird, wird dann allerdings an der 4. 
Stelle (Zahlerstand 3) eine NO_ENTRY-Codierung stehen, um das 
Fehlen dieser Operation anzuzeigen; ein derartiger LUT-Ein- 
15 trag ist in Figur 3B veranschaulicht . 

Die besagten Zahler sind im betrachteten Beispiel Binarzahler 
mit asynchronem Reset und Enable. Ein 2-Bit-Binarzahler die- 
ser Art ist im betrachteten Beispiel wie folgt codiert; die 
20 Darstellung erfolgt in dem bei DNF (Dis junktive Normal-Form) - 
Logiken gebrauchlichen DNF-Format. zahler dieser Art werden 
im folgenden als . Zahler eines ersten Typs bezeichnet. 

^ BIT bO, bl:OUT; 
25 BIT reset, enable: IN; 
BIT clock: IN; • 



bO = /bO * enable + bO * /enable; 
bO.clk = clock; 
30 bO.areset = reset; 

bl = /bl * bO * enable + bl * /bO * enable + bl * /enable; 
bl.clk = clock; 
bl.areset = reset; 



35 
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Parallel zu diesen Zahlern muB fiir die bedingten Befehle ein 
Speicherarray implementiert seiri;, um den Code des Bedingungs- 
flags speichern zu konnen. Dies ist, wie vorstehend bereits 
erlautert wurde, zur Zusammenset zung von Movep-Bef ehlen not- 
wendig. Da es nur eine CU-Instanz pro Flag geben Jcann (im 
Gegensatz zu den AUs gibt es zwar im allgemeinen mehrere 
Flags, die sich jedoch alle durch die Bezeichnung des Bits 
unterscheiden) , besteht der Binarzahler aus zwei Bits, von 
denen das erste die Erstbelegung, und das zweite die Komple- 
mentarbelegung anzeigt. Die Ident if izierung der korrekten CU 
erfolgt anhand der p-Bits aus dem Befehl. 

Die 2-Bit-Binarzahler fiir bedingte Move-Bef ehle sind im 
betrachteten Beispiel wie folgt codiert; die Darstellung 
erfolgt wiederum in dem bei DNF (Dis junktive Normal-Form) - 
Logiken gebrauchlichen DNF-Format. Zahler dieser Art werden 
im folgenden als Zahler eines zweiten Typs bezeichnet. 

BIT bO, bl:OUT; 

BIT reset, enable: IN; 

BIT clock: IN; 

bO = /bO * enable + bO; 
bO.clk = clock; 
bO.areset = reset; 

bl - /bl * bO * enable + bl; 
bl.clk = clock; 
bl.areset = reset; 

Fur die Falle, in denen Entscheidungen getroffen werden mus- 
sen, die in Datenpfade umgesetzt werden, wird eine spezielle 
Logik integriert- 
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Fiir die 1. Phase des Verfahrens zur Hardware-Block-Struktu- 
rierung ergibt sich nach alledem die in Fig. 4 gezeigte 
Realisierung . 

Fur alle Befehle mit Ausnahme der bedingten Movep-Instruktio- 
nen wird pro arithmetischer Einheit AU bzw. pro Vergleichs- 
Einheit CU eine Zahlerinstanz nach Art des vorstehend erlau- 
terten Zahlers des ersten Typs benotigt. Ein solcher Zahler 
genugt, da nur ein einfaches Belegt-Signal benotigt wird. Die 
Movep-Anweisungen hingegen benotigen einen Zahler des zweiten 
Typs, der in zwei Bits die teilweise (bO) und die vollstan- 
dige (bl) Belegung signalisiert . Bedingte Movep-Instruktio- 
nen, die zum zweiten Mai auf das gleiche Flag ref erenzieren, 
mussen dieses in (im Vergleich zur ersten Referenz) inver- 
tierter Form vornehmen und werden dann in der entsprechenden 
AU als zweite Quelle eingetragen, wahrend das erste Quell- 
register unverandert bleibt. Dieses Verfahren ist in einer 
LUT integrierbar ; Referenzen auf die nicht invertierten 
Bedingungen werden durch eine No_Entry-Signalisierung ab- 
gebrochen . 

Die zweite Phase umfaiit die Bestimmung der Register, die fur 
die betreffende Operation als Daten- und/oder Signalquelle (n ) 
und Daten- und/oder Signalziel zu verwenden sind. Dies er- 
folgt fur alle drei moglichen Register in paralleler und 
weitgehend identischer Form. Die Codierung des jeweiligen 
Registers innerhalb der Instruktion wird - falls das betref- 
fende Feld einen giiltigen Eintrag enthalt - durch eine Look- 
Up-Table in eine Maske fiir den Bitstrom zusammen mit dem 
Index in den Bitstrom umgesetzt. 

Das Blockschaltbild einer Schaltung zur Bestimmung und Codie- 
rung der als Daten- und/oder Signalquelle (n) und Daten- 
und/oder Signalziel zu verwendenden Register ist in Figur 5 
veranschaulicht ; die Identif izierung, welche der Register 
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tatsachlich umgesetzt werden (mussen) , erfolgt im betrachte- 
ten Beispiel durch die Steuerleitungen Source Reg 1, 
Source_Reg_2, und Dest_Reg (siehe Figuren 4 und 5) . 

Source- und Destinationregister werden unterschiedlich behan- 
delt. Im Fall eines Destinationregisters wird der Eintrag 
markiert, um eine Zweitbelegung identif izieren zu konnen 
(Signal No_Entry) und um ein Data Forwarding zu triggern. 
Diese Signale entfallen fur Sourceregister . Hier wird eine 
"straight-forward"-Generierung des Bitstromeintrags durch- 
gefuhrt, wobei allerdings die Generierung des Codes im Fall 
einer Konstanten entfallt und auf die nachfolgend beschrie- 
bene Stufe verlagert wird. 



In der Figur 5 ist markiert, was ausschlieJilich fur Source- 
register und ausschlielilich fur Destinationregister relevant 
ist: mit (*) gekennzeichnete Teile sind nur fur Destination- 
register bestimmt, und mit gekennzeichnete Teile sind 
nur fur Sourceregister bestimmt. 

Fur eine Konstante, die innerhalb der Codierung anstelle 
eines Sourceregisters auftreten kann, wird ein paralleler Wei 
durchgefiihrt, der die Konstante mit den Inhalten aller Kon- 
stantenregister parallel zueinander vergleicht, und - bei 
Ungleichheit - das nachstfreie Register ( Zeigerverwaltung 
durch einen Zahler) mit der Konstanten belegt und dieses 
Register als Codierung zuriicklief ert oder - bei Gleichheit - 
die Codierung des die Konstante enthaltenden Konstantenregi- 
sters als Codierung zurucklief ert . 

Die Look-Up-Table wird zu diesem Zweck so gestaltet, dafi sie 
bei einem positiven Vergleich unmittelbar die Codierungs- 
nummer des betreffenden Registers zum Bitfeld liefert, wah- 
rend im Fall einer Nichtubereinstimmung zusatzlich die Kon- 
stante gespeichert und der Register zahler erhoht wird.. Das 
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No__Entry-Signal wird ftir den Fall einer Belegung aller Kon- 
stanten aktiv und beendet den Algorithmus fur einen Instruk- 
tionsblock, da die Ressourcen erschopft sind. Es sollte zudem 
beachtet warden, dafJ die Konstantenregsiter ein Teil des 
(Main-) Bitstroms sind, da sie aus vorhergehenden Zyklen be- 
reits belegt sein konnen und zum Laden des Instruktionsblocks 
benotigt werden. 

Das Blockschaltbild einer Schaltung zur Zuordnung der Kon- 
stantenregister ist in Figur 6 veranschaulicht . 

Fur Sourceregister wird das bereits mehrfach erwahnte Data 
Forwarding durchgef uhrt . Anhand der Eintragung in das 
Belegtflag des Registers, die anzeigt, dafi dieses Register in 
diesem Zyklus bereits Zielregister war, wird entschieden, ob 
tatsachlich das Sourceregister oder die Eintragung, die als 
Quelle fur das Zielregister ermittelbar ist, als neue Quelle 
in den Bitstrom eingetragen wird. 

Das Blockschaltbild einer hierzu geeigneten Schaltung ist in 
Figur 7 dargestellt. 

Die im Figur 7 per LUT durchgef uhrte Umcodierung der neuen 
Quelle kann entfallen, falls alle Quellen innerhalb des Netz- 
werks identisch codiert werden. Dieser Fall, der fur ein 
vollstandiges Netzwerk angenommen werden kann, fuhrt dazu, 
daft die im temporaren Bitstrom stehende Eintragung der Quelle 
fur das (fruhere) Zielregister als neue Quell-Codierung fur 
die jetzige Operation anstelle des in der Instruktion codier- 
ten Quellregisters eingetragen wird. Die Auswahl erfolgt in 
jedem Fall durch einen uber das Signal Is_Data-Forwarding 
(siehe Figur 5) angesteuerten Multiplexer. 

Fuhren alle Operationen zum Erfolg (dies ist anhand des Auf- 
tretens keiner No_Entry-Signalisierung erkennbar) , wird der 
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temporare Bitstrom beim Schreibtakt mit dem vorhandenen 
Hauptbitstroiu ODER-ver knupf t und in diesen zuruckgeschrieben . 

Die Figuren 8 und 9 zeigen Blockschaltbilder zum Einschreiben 
5 von Konf igurationsdaten in den temporaren Bitstrom und in den 
Hauptbitstrom (main bitstream) . 

Wie aus der Figur 8 ersichtlich ist, erfolgt das Einschreiben 
von Konf igurationsdaten in den temporaren Bitstrom iiber soge- 
10 nannte Cross-Bar-Switches. Cross-Bar-Switches sind allgemein 
bekannt und bedurfen keiner naheren Erlauterung, Sie leiten 
die Konf igurationsbits (Conf ig-Bits) an die durch den Config- 
Index definierten Stellen im temporaren Bitstrom, wobei unbe- 
legte Ausgange des Cross-Bar-Switch mit einem vorbestimmten 
15 Wert (beispielsweise "0") belegt sind. Fiir die mnemonic- 

basierte Auswahl einer physikalischen Teileinheit, die Konfi- 
guration derselben und die Zuordnung der Source- und Destina- 
tionregister zu dieser ist jeweils ein eigener Cross-Bar- 
Switch gemali Figur 8 notwendig. 



20 



1^ 



25 



Die Umsetzung des temporaren Bitstroms in den Hauptbitstrom 
(die Uberlagerung des Hauptbitstroms durch die Ausgange der 
Cross-Bar-Switches erfolgt durch ODER-Gatter OR am Eingang 
des Hauptbitstroms (siehe Figur 9) . 



Die vorstehend beschriebenen Komponenten lassen sich wie in 
Figur 10 gezeigt zu einer Anordnung zusammenf ugen, die in der 
Lage ist, aus m-bits, ksl-Bits, ks2-Bits, kd-Bits und p-Bits 
zusammengesetzte Befehle (siehe Figuren lA bis ID) in Konfi- 
30 gurations-Daten zur Konf igurierung eines Hardware-Blocks 

umzusetzen und diese Oaten in einen zur Konf igurierung des 
Hardware-Blocks verwendbaren Bitstrom einzuschreiben . 
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Abschlieilend wird die angestrebte Umsetzung (die struktur- 
prozedurale Prograromierung) auch noch in mathematischer Nota- 
tion angegeben, 

Hierzu muB zunachst eine Reihe von die Darstellungen und die 
Abbildungen betreffenden Vereinbarungen getroffen werden. Es 
seien 



I"^ die Menge aller Instruktionen 

I die Menge aller Datenf lufi-relevanten (fur die 

Blockausf iihrung geeigneten) Instruktionen 
SR . die Menge aller Sourceregister einschlieftlich NO- 

>^ SOURCE-Darstellung^ ausschliefilich der Konstanten- 

register 

CR die Menge aller Konstantenregister einschliefilich 

der Darstellungen fur NO_CONST und IS_CONST 
SR"" SR U CR 

DR die Menge aller Destinationregister einschliefilich 

NO_DEST-Darstellung ausschlieJilich der Predicate- 
Bits 

PR die Menge aller Predicate-Bits einschlieJ31ich 

NO_PRED 

DR"" DR U PR 

RN die Menge aller Register, SR u CR u DR 

RN"^ die Menge aller Register einschlieftlich Predicate 

Bits, RN u PR 



List(pp) die Menge aller moglichen Werte fur den Bitstrom B 
als 4-Tupel (px g PP, offset < k, nbit < k, bitwert 
< 2^ - 1) , gegebenenf alls abhangig von pp e PP 

Nbit die Menge der moglichen Bitwerte (bei n Bit Daten- 

breite: 0 . . 2^" - 1) 

B die Menge von k binarwert igen Eintragen als der 

Bitstrom zur Konf iguration der Struktur 
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die Menge aller Belegungsmarkierungen {FREE, WRITE, 
READ, READ_WRITE} 

die Menge aller physikalischen Teileinheiten 
die Menge aller eindeutigen Nummern fur die logi- 
schen Einheiten 

die Menge aller logischen Teileinheiten in einem 
CB, bestehend aus dem 11 -Tupel (pi g I u RN"^, 
plnum e PLNUM, pp e PP, occ e OCC, source g PLNUM, 
val e Nbit, pbit g PR, List (pp) , konfOffset < k, 
konfAnzahl < k, konfWert < 2*" - 1) 

Bei der folgenden Beschreibung werden einige Grundannahmen 
und Funktionen genutzt, die zunachst erlautert werden sollen. 
Die Kennung innerhalb der Komponente occ (fur occurence) 
wurde vierwertig gewahlt, um die Zustande 'nicht belegt ' 
(FREE), 'lesend belegt • (READ), ' schreibend belegt' (WRITE) 
und ^lesend und schreibend belegt* (READ_WRITE) kennzeichnen 
zu konnen. Die Kennung 'lesend belegt' wird dabei gegebenen- 
falls nicht welter ausgewertet, aber dennoch innerhalb der 
Beschreibung weitergef iihrt . 

Weiterhin wird fur die Register aus RN angenommen, daft fur 
diese Teileinheiten die logische und physikalische Darstel- 
lung ubereinstimmt . Dies bedeutet, dafl im Gegensatz zu man- 
cher funktionalen Teileinheit (etwa eine konf igurierbare 
Addition/Subtraktionseinheit die als zwei logische Einheiten 
dargestellt wird, aber naturlich nur einmal belegbar ist) fur 
Register keine Konf igurierung durchzuf uhren ist, und daB 
zwischen der Registernummer rn e RN und der logischen Teil- 
einheitsnununer plnum g PLNUM eine injektive Abbildung 
(gleichwohl nicht bijektiv) existiert, die im folgenden mit 
rn2plnum() bezeichnet wird. Diese Annahme gilt nicht fur 
Predicate-Bits als Zielbits. 



OCC 
PP 

PLNUM 
PL 
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Unter diesen Vorausset zungen lalit sich die Umsetzung von 
Befehlen in Strukturinf ormationen zur Strukturierung von 
Hardware-Blocken wie folgt umschreiben: 

1. In der ersten Phase wird jede Instruktion einschlieftlich 
aller Operanden aus dem originalen Binarformat in eine 
Beschreibung hi = (i e I, srl e SR, crl e CR, nl g 
Nbit, sr2 e SR, cr2 e CR, n2 e Nbit, dr e DR, pr_source 
e PR, pr___dest e PR) ubergefuhrt. In dieser Beschreibung 
wird fur eine Konstante die Kennung IS_CONST fur crl 
bzw. cr2 sowie der Konstantenwert in nl/n2 eingetragen, 
wobei in diesem Fall das entsprechende Sourceregister 
die Kennung NO_SOURCE erhalt. Entsprechend wird fur Pre- 
dicate-Bef ehle (etwa pge fur dr NO_DEST eingesetzt, 

wahrend pr_dest dann die Nummer des Predicate-Bits 
tragt . 




Fur Predicated Instructions (etwa movep) wird zur besse- 
20 ren Unterscheidbarkeit nicht pr_dest, sondern pr_source 

auf einen entsprechenden Wert gesetzt. 

^ Eine Instruktion mit j ^ I bewirkt ein Beenden der Um- 

setzung. 



25 



30 



In der zweiten Phase werden maximal funf Eintrage in bi 
in eine Konf iguration ubersetzt. Funf deshalb, da sich 
einige Kombinationen gegenseitig ausschlieflen . Hierzu 
wird fur die einzelnen Telle unterschieden : 

Fur Instruktionen bi->i € I und bi^pr_dest == NO_PRED 
(keine Predicate-Anweisung) wird das erste Element pi e 
PL gesucht, das dieses i abdeckt und occ == FREE auf- 
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weist. 1st dies nicht auffindbar, so wird die Umsetzung 
beendet . 

1st pi gefunden, so warden alle Elemente aus PL mit occ 
== READ_WRITE belegt, die auf das selbe physikalische 
Element pp e PP abgebildet sind . Die Konf iguration fur 
pi wird in den Bitstrom B mit Hilfe der im Tupel vorhan- 
denen Inf ormationen eingetragen . 

1st bi— >pr_source == NO_PRED, so wird hierfur keine Ein- 
tragung durchgef iihrt . Ansonsten wird nach einem p2 e 
PL mit p2— >pbit == bi— >pr_source gesucht, wobei p2— >occ 
== WRITE sein mul5 . Fur dieses p2 wird via List {p2->pp) 
pi gesucht und die Eintragung in den Bitstrom vorgenom- 
men, aufterdem wird p2— >occ auf READ_WRITE gesetzt. 

Fur Instruktionen bi— >i e I und bi->pr_dest != NO_PRED 

(Predicate-Anweisung) wird das erste Element pi e PL 
gesucht/ das dieses i abdeckt und occ == FREE aufweist. 
1st dies nicht auf f indbar , so wird die Umsetzung be- 
endet . 

1st pi gefunden, so werden alle Elemente aus PL mit occ 
= WRITE belegt, die auf das selbe physikalische Element 
pp € PP abgebildet sind. Die Konf iguration fur pi wird 
in den Bitstrom B mit Hilfe der im Tupel vorhandenen 
Inf ormationen eingetragen , 

Fiir alle Instruktionen i g I gilt: Fur bi— >srl und 
bi->sr2/ fur die != NO_SOURCE gilt, wird durch 
List(pl->pp) die entsprechende Konf iguration in den 
Bitstrom B eingesetzt , falls fiir die zu srl/2 gehorigen 
pll/12 e PL, pll-»occ == FREE, und pl2->occ FREE 
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gilt, zudem wird pi— >plnum bei pll/12->source eingetra- 
gen (fiir spateres Forwarding) . 1st dies nicht der Fall, 
wird Phase 3 (Data Forwarding) durchgef uhrt . 

Fur die Sourceregister bi->srl und bi->sr2 wird, falls 
diese != NO^SOURCE sind, in PL die ent sprechenden Ein- 
trage fur die zugehorigen p31 und p32 g PL (erhaltlich 
liber die angegebene Funktion rn2plnum()) p31->occ und 
p32->occ auf READ gesetzt, falls diese vorher != WRITE 
und != READ_WRITE waren, ansonsten auf READ_WRITE. 

Fur die Konstantenregister crl und cr2 wird, falls diese 
!= NO_CONST sind, zunachst fur alle p3 g PL gepruft, ob 
p3->pp e CR, p3->occ == READ_WRITE, und p3->val == 
bi->nl/2 gilt. 1st dies der Fall, wird die Eintragung 
fiir p3 entsprechend dem Verfahren fur ein Sourceregister 
durchgef lihrt . 

Fuhrt diese Suche nicht zum Erfolg, muft ein p3 e PL ge- 
sucht werden, fur das p4^pp e CR und p4->occ == FREE 
gilt, 1st dies gefunden, wird bi->nl/2 in p4-)^val ein- 
getragen und p4^occ = READ__WRITE gesetzt sowie die Ein- 
tragung wie bei einem Sourceregister fortgefuhrt. 1st 
die Suche erfolglos, wird die Umsetzung beendet. 

Fur das Destinat ionregister dr wird gepruft, ob fur den 
entsprechenden Eintrag p5 mit p5->pp == dr die Bedingung 
p5->occ == FREE Oder READ gilt. 1st dies nicht der Fall, 
wird die Umsetzung beendet, ansonsten wird p5->occ = 
WRITE Oder READ_WRITE gesetzt und die Eintragung in 
List(p5^pp) wird in den Bitstrom B iibertragen. Fur ein 
eventuelles Data Forwarding wird p5— ^source = pi 
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(logisches Element der wertgebenden Instruktion) einge- 
tragen . 

3. Ftir alle Sourceregister sr e SR, die in Phase 2 den 

Wert fur das zugehorige Element p6 g PL den Wert p6— >occ 
== WRITE Oder READ_WRITE aufweisen, wird ein Data For- 
warding durchgef uhrt, indem in den Bitstrom B nicht die 
Werte aus List(p6), sondern aus List (p6->source) ein- 
getragen werden. 

Die vorstehenden Darstellungen und Realisierungsmoglichkeiten 
bezogen sich jeweils auf einen Hardware-Block der in der Fi- 
gur 12 gezeigten Art. Es durfte einleuchten, dafi hierauf 
keine Einschrankung besteht. Die beschriebene Umsetzung von 
Befehlen oder Bef ehlsf olgen in Hardware-Block-Strukturen lafit 
sich dem Wesen nach auch bei modif izierten oder erweiterten 
Hardware-Blocken realisieren. Sie ermoglicht es unabhangig 
hiervon, konf igurierbare Hardware-Blocke automatisch zu kon- 
figurieren, wobei die Konf iguration sehr schnell durchfuhrbar 
ist, die Komponenten des Hardware-Blocks optimal ausnutzbar 
sind, und einen aufierst effektiven Betrieb des Hardware- 
Blocks ermoglicht . 
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Patent anspruche 

1- Verfahren zum Konf igurieren eines konf igurierbaren Hard- 
ware-Blocks, so daft dieser durch Befehle oder Bef ehlsf olgen 
vorgegebene arithmetische und/oder logische Operationen oder 
Operationsf olgen ausfiihren kann, 
dadurch gekennzeichnet, 
daft fur die Umsetzung der abzuarbeitenden Befehle in eine 
Hardware-Block-Struktur die Schritte 

- Ermittlung der zur Ausfuhrung eines jeweiligen Befehls be- 
notigten Art von Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) 
des konf igurierbaren Hardware-Blocks, 

- Auswahl einer noch nicht anderweitig belegten Teileinheit 
der zuvor ermittelten Art, und - sofern eine solche Teil- 
einheit gefunden werden konnte - 

- Konf igurieren von urn die ausgewahlte Teileinheit herum vor- 
gesehenen konf igurierbaren Verbindungen 

ausgef uhrt werden . 

2. Verfahren nach Anspruch 1, 
dadurch gekennzeichnet, 

daft die Umsetzung mit dem ersten Befehl eines nur einen Ein- 
trittspunkt und einen Austrittspunkt aufweisenden Befehls- 
Blocks begonnen wird. 

3. Verfahren nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

daft die Umsetzung nach dem Umsetzen des letzten Befehls eines 
nur einen Eintrittspunkt und einen Austrittspunkt aufweisen- 
den Bef ehls-Blocks automatisch beendet wird. 

4. Verfahren nach Anspruch 2 oder 3, 
dadurch gekennzeichnet, 
daft die Umsetzung hyperblock-weise erfolgt. 
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5. Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

dafi die Umsetzung automatisch beendet wird, wenn eine zur Um- 
setzung benotigte Komponente des Hardware-Blocks nicht oder 
5 nicht mehr verfiigbar ist, 

5. Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 
dali f unktionsmaliig konf igurierbaren Teileinheiten (AUx, CU, 
10 DEMUX, MUXAx, MUXB) des Hardware-Blocks virtuelle Einheiten 
zugeordnet werden^ wobei die virtuellen Einheiten Funktionen 
reprasentieren, welche der betreffenden Teileinheit durch 
unterschiedliche Konf igurationen verliehen werden konnen . 

15 7. Verfahren nach Anspruch 6, 

dadurch gekennzeichnet, 

daB die virtuellen Einheiten samtlicher physikalischer Teil- 
einheiten (AUx, CU, DEMUX, MUXAx, MUXB) in einer Tabelle oder 
Liste eingetragen sind, 

20 

8. Verfahren nach Anspruch 7, 
dadurch gekennzeichnet^ 

dali die Tabellen- oder Listeneintrage Inf ormationen dariiber 
enthalten, welcher physikalischen Teileinheit (AUx^ CU, 
25 DEMUX, MUXAx, MUXB) die betreffende virtuelle Einheit zu- 
geordnet ist. 

9. Verfahren nach Anspruch 7 oder 8, 
dadurch gekennzeichnet, 

30 daft die Tabellen- oder Listeneintrage Inf ormationen daruber 
enthalten, wie die zugeordnete physikalischen Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) zu konf igurieren ist, urn ihr 
die durch die virtuelle Einheit reprasentierte Funktion zu 
verleihen . 



35 
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10. Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

dal5 die Auswahl einer zur Ausfuhrung eines Befehls benotigten 
Teileinheit (AUx, CU, DEMUX, MUXAx, MUXB) uber eine Suche 
5 nach einer virtuellen Einheit der benotigten Art erfolgt. 

11. Verfahren nach Anspruch 10, 
dadurch gekennzeichnet, 

dali dafiir gesorgt wird, daii die zur Verwendung ausgewahlte 
10 virtuelle Einheit der benotigten Art und diejenigen virtuel- 
len Einheiten^ die der selben physikalischen Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) zugeordnet sind wie die aus- 
gewahlte virtuelle Einheit, bei nachf olgenden Umsetzungen 
nicht mehr zur Verwendung ausgewahlt werden konnen . 

1!3 

12. Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

dali beim Konf igurieren der um die ausgewahlte Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) herum vorgesehenen konfigurier- 

20 baren Verbindungen zur Verbindung der betreffenden Teilein- 
heit mit einer durch den umzuset zenden Befehl definierten 
Daten- und/oder Signalquelle iiberpruft wird, ob die betref- 
fende Daten- und/oder Signalquelle ein Speicherbereich ist, 
\^ der zuvor durch eine der Teileinheiten des Hardware-Blocks 

25 beschrieben wurde. 

13. Verfahren nach Anspruch 12, 
dadurch gekennzeichnet, 

dafi dann, wenn festgestellt wird, dafi die durch den umzuset- 
30 zenden Befehl definierte Daten- und/oder Signalquelle zuvor 
durch eine der Teileinheiten (AUx, CU, DEMUX, MUXAx, MUXB) 
des Hardware-Blocks beschrieben wurde, diese Teileinheit als 
Daten- und/oder Signalquelle verwendet wird. 



35 



14. Verfahren nach einem der vorhergehenden Anspriiche, 
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dadurch gekennzeichnet, 

dafii beim Konf igurieren der um die ausgewahlte Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) herum vorgesehenen konfigurier- 
baren Verbindungen zur Verbindung der betreffenden Teil- 
einheit mit einem durch den umzuset zenden Befehl definierten 
Daten- und/oder Signalziel uberpruft wird, ob das betreffende 
Daten- und/oder Signalziel ein Speicherbereich ist, der auch 
durch eine andere Teileinheit des Hardware-Blocks beschrieben 
wird . 

15. Verfahren nach Anspruch 14, 
dadurch gekennzeichnet, 

dafi dann, wenn festgestellt wird, dai5 das durch den umzuset- 
zenden Befehl definierte Daten- und/oder Signalziel ein 
Speicherbereich ist, der auch durch eine andere Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) des Hardware-Blocks beschrieben 
wird, ein anderer Speicherbereich als Daten- und/oder Signal- 
ziel verwendet wird. 

16. Verfahren nach Anspruch 15, 
dadurch gekennzeichnet, 

daft fur die das selbe Daten- und/oder Signalziel reprasentie- 
renden Speicherbereiche das bei superskalaren Prozessoren an- 
gewandte register renaming durchgefuhrt wird. 

17. Verfahren nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 

daft dann, wenn im umzuset zenden Befehl eine Konstante enthal- 
ten ist, nach einem die Konstante enthaltenden Konstanten- 
Speicherbereich gesucht wird und dann, wenn ein solcher Kon- 
stanten-Speicherbereich gefunden wurde, dieser Konstanten- 
Speicherbereich als Daten- und/oder Signalquelle verwendet 
wird . 
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18. Verfahren nach Anspruch 17, 
dadurch gekennzeichnet, 

dali dann, wenn die Konstante nicht bereits in einem der vor- 
handenen Konstanten-Speicherbereiche gespeichert ist, die 
Konstante in einen neuen Konstanten-Speicherbereich gespei- 
chert wird, und dieser neue Konstanten-Speicherbereich als 
Daten- und/oder Signalquelle verwendet wird. 
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Zusammenf assung 

Verfahren zum Konf igurieren eines konf igurierbaren Hardware- 
Blocks 

5 

Die Hardware-Block-Konf igurierung erfolgt basierend auf 
Befehlen oder Bef ehlsf olgen, wobei jeweils die Schritte 

- Ermittlung der xzur Ausfuhrung eines jeweiligen Befehls 
benotigten Art von Teileinheit des konf igurierbaren 

10 Hardware-Blocks, 

- Auswahl einer noch nicht. anderweitig belegten Teileinheit 




der zuvor ermittelten Art, und 



- Konf igurieren von um die ausgewahlte Teileinheit herum 
vorgesehenen konf igurierbaren Verbindungen 
15 ausgefuhrt werden. 

Figur 1 
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Bezugszeichenliste 



1 predecode unit 

2 instruction buffer 

3 decode, rename & load unit 

4 s-unit 

5 data cache 

6 memory interface 

41 programmable structure buffer 

42 functional unit with programmable structure 
i^jj^^- 43 integer/address instruction buffer 

44 integer register file 

AUx arithmetische Einheit 

CU Vergleichs-Einheit 

DEMUX Demultiplexer 

MUXAx Multiplexer des ersten Typs 

MUXB Multiplexer des zweiten Typs 
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